On 17 July 2016 at 01:31, Brad Fitzpatrick <[email protected]> wrote: > On Fri, Jul 15, 2016 at 8:48 PM, Gergely Imreh <[email protected]> wrote: >> >> On 16 July 2016 at 01:50, Mathieu Lonjaret <[email protected]> >> wrote: >> > ACK, will do. >> >> Thanks, I've tried it out, and with the patchset 2 from your link, and >> I can use the CLI tools. >> >> > >> > On 15 July 2016 at 19:48, Brad Fitzpatrick <[email protected]> wrote: >> >> Instead of auto-detection, let's make this very opt-in and explicit and >> >> add >> >> a new client config option to "disabledHTTP2": true. >> >> Just as an observation, all other tools handle protocol downgrade >> transparently (browsers, curl, etc..). I think it would be a lot nicer >> user expereice to have that sort of behaviour in camlistore too, >> especially since the servers already give a hint whether or not they >> handle http/2. >> So for example, trying the curl commands in the `clients/curl` >> examples (just the https versions to this particular server), it >> automatically handles all this and can talk to the same camlistore >> server over the same proxy, that the CLI tools cannot. > > Let's just say that given how much of an improvement HTTP/2 is > (especially wrt to end-to-end encryption), the official stance of the > project is to encourage its adoption as much as possible. Making it > easy to downgrade would go contrary to that goal. So now you can tell > resin.io to clean up their act, or you'll be leaving them for someone > that does support HTTP/2 correctly ;)
Well, since I'm working at resin.io (as developer evangelist), I won't be leaving them for this tiny thing. :) But started the internal discussion and have a ticket to upgrading to http/2, when it checks out that it doesn't interfere with the other use cases (I think it shouldn't be big of a deal, just due diligence) What you and Brad are saying makes sense regarding the official stance, and I have no problem with it. Sill I wanted to mention, that probably I'm forgiven thinking that this is a bug, not a feature, since no HTTP/2 is mentioned on the entire Camlistore website (except in code), nor was the original error message very helpful to signal a design decision (as opposed to software failure). It would be probably useful to make it "really official", if you don't want to run into similar issues in the future of people misunderstanding (explicitly highlighting on the website, mentioning in the "baseURL" section maybe when you talk about reverse proxies, in the error message when can't connect to the server over http/2). Also, if it's an official stance, then maybe the entire changeset does not make much sense to actually use from your point of view, as it is a "temporary workaround of dubious quality" (forgive my paraphrasing). I'm happy either way in the light of that (committed or not), as now I understand your requirements more, all these qualifications were badly needed. > As Mathieu said, we really want to encourage HTTP/2, which lets us make a > bunch of assumptions which simplifies our code (e.g. previously we were > planning our own batch blob PUT API, which is redundant with HTTP/2). > Normally end-to-end HTTPS means you can do whatever you want and proxies > won't interfere and break your code. If we know it's our code talking to our > code, we know WebSockets will work for instance. Once you have a proxy > involved, the proxy almost invariably shits over everything. Yeah, that's true, that proxies make things more complicated. For a lot of use cases, they look are pretty inevitable, for better or worse. Most web applications shouldn't be directly exposed to the net, but have some more unified way (e.g. nginx) to take whatever is thrown on it. I understand that it is not your main use case, and it complicates things, so not saying you need to / should change anything. Just what I see from experience. By the way, temporarily fixed things by adding a http/2/ALPN enabled nginx proxy in front of the resin.ip proxy, seems to be working fine (both CLI and web including websockets). > We can totally do automatic downgrade if we wanted to (Go's net/http package > does, for instance, and we used to go through it for all our HTTP), but we > made the decision to hard-code http2 so when something doesn't work, the > user has to very explicitly acknowledge they're running in an unsupported > configuration and things may not work well. Your uploads may be very slow > due to lack of batch requests in http2. Your web UI may not work due to lack > of websockets. Etc. I see your point. In this case more information is very much needed. I don't think there was a way beforehand for the user to "explicitly acknowledge" anything, it just broke on the CLI, and worked just fine on the web without any warning, in a sort of inconsistent experience. Adding the config option as per changeset 2 does feel like a step forward to the situation you describe indeed. > > I care about Camlistore's existence over the coming decades (as services > continues to shut down), so waiting out a temporary phase of HTTP/2 not > being universally deployed is okay at the moment. Its adoption has been > pretty impressive. I'm pretty sure resin.io will upgrade eventually. > Yeah, deployment is a tricky thing. One watershed moment might be Ubuntu 16.04.1 LTS, which will likely see the update from 14.04 LTS - the openSSL shipped with the current (old) server cannot do ALPN even if for example nginx does HTTP/2 just fine (this might be a case to consider, that there can be one without the other, and camlistore seems to need both) Cheers, Greg -- You received this message because you are subscribed to the Google Groups "Camlistore" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
