<FromGitter>
<dscottboggs_gitlab> provide you an easy way to register the constraint while abstracting the special naming scheme so that a user doesn't have to know how that all works
<FromGitter>
<jwoertink> I thought it just came from the `REMOTE_ADDRESS` header, but looks like it doesn't
<FromGitter>
<jwoertink> what I'm trying to do here is I want to test something, and I want to set that value, and test for it, but I only have access to the context with `HTTP::Request.new` and the response
<FromGitter>
<jwoertink> oh, I can just assign it to the request object
<FromGitter>
<jwoertink> cool, that works
<FromGitter>
<jwoertink> hashtag rubberduck
<sorcus>
Hi guys.
<FromGitter>
<dscottboggs_gitlab> hi
<watzon>
sorcus: 👋
<sorcus>
`Unhandled exception: Unsupported HTTP version: HTTP/2 (Exception)` - should be `HTTP/2` added to HTTP::SUPPORTED_VERSIONS?
<FromGitter>
<dscottboggs_gitlab> @jwoertink I think that value is checked for in a few locations, like `X-Remote-Address` etc
<FromGitter>
<dscottboggs_gitlab> hahahaha
<FromGitter>
<dscottboggs_gitlab> good luck, sorcus
<FromGitter>
<dscottboggs_gitlab> apparently http/2 is wayyy more complicated than 1.1
<FromGitter>
<dscottboggs_gitlab> I feel like it would be better to try changing the request value to `HTTP/1.1` than to add `HTTP/2` to supported versions. An `HTTP/2` request can contain only things that are valid for `HTTP/1.1` so it's worth a shot either way. Just be sure you wrap the exception and note why it's being thrown, because it probably will fail at some point.
<FromGitter>
<Blacksmoke16> not actually true ^
<FromGitter>
<Blacksmoke16> `HTTP/1.1` headers are case insensitive, while in `HTTP/2` they should be lowercase
<FromGitter>
<dscottboggs_gitlab> ^ this dude often knows more than me
<FromGitter>
<Blacksmoke16> granted idk much about `HTTP/2` but that one is one diff im aware of
<FromGitter>
<Blacksmoke16> oh wait i misread i think
<FromGitter>
<dscottboggs_gitlab> does what I said make sense, with that in consideration? like yes, for that request, it makes sense to just say "yup this is ok" but if a server is expecting to be able to serve up 2 and you're trying to parse it as 1.1 you will probably run into some weird stuff
<FromGitter>
<jwoertink> HTTP/3 will end up being a thing before HTTP/2 becomes standard
<FromGitter>
<jwoertink> Which I guess is going to be designed after QUIC? or something??
<FromGitter>
<dscottboggs_gitlab> ayyup
<FromGitter>
<dscottboggs_gitlab> because TCP isn't good enough, we've gotta put the handshaking into the HTTP protocol too
<sorcus>
So what should i do make for parsing raw response via HTTP::Client::Response without patching stdlib?
<FromGitter>
<dscottboggs_gitlab> if the response is in `HTTP/2` I don't think there's a good answer in Crystal unfortunately.
<FromGitter>
<dscottboggs_gitlab> perhaps you can request that the server respond only with `HTTP/1.1` in a header?
* FromGitter
* dscottboggs_gitlab googles
<sorcus>
dscottboggs_gitlab: Yeah, i can do it with `--http1.1` or `--http1.0`.
<FromGitter>
<dscottboggs_gitlab> no I mean, perhaps in the request you can send a header which indicates to the server that the client can only understand 1.1
<sorcus>
dscottboggs_gitlab: Hmm... `curl --help` -> `--http1.1 Use HTTP 1.1`
<FromGitter>
<dscottboggs_gitlab> oh I see now
<FromGitter>
<dscottboggs_gitlab> I can't find anything, I'd ask on stackoverflow or something if there is a way to request a particular HTTP version via a header
<sorcus>
dscottboggs_gitlab: There is no header for switching HTTP version as i know. But can be switched with request line `GET / HTTP/1.1`
<FromGitter>
<dscottboggs_gitlab> oh, that makes sense
<sorcus>
dscottboggs_gitlab: This should be a good solution i think...
<FromGitter>
<dscottboggs_gitlab> `return nil` is the same as just `return`. Also I would put a `begin..rescue` block around the Response.new constructor, which logs an extra note if the `http_version == "HTTP/2"`, and then raises. ⏎ ⏎ otherwise looks solid
<sorcus>
dscottboggs_gitlab: Thank you for your recomendations. :-)
<FromGitter>
<dscottboggs_gitlab> no problem, hope I've helped a little
<sorcus>
dscottboggs_gitlab: Yeah, your help is very useful for me.
<FromGitter>
<dscottboggs_gitlab> thanks! 😀
_ht has quit [Quit: _ht]
<sorcus>
Good night :-)
<FromGitter>
<smalls12> Channels have a non-blocking parameter, im guessing that means that when you call send/receive it will return instantly instead of sitting there
<FromGitter>
<smalls12> ( whoops that was a question )
<FromGitter>
<Blacksmoke16> right, afaik it would return `nil` if there is no value currently available to receive, otherwise returns that value