Done in r1740075. I was thinking of a nicer solution, but that involved inventing new hooks which seems not worth it.
Since this area of protocol negotiation has already been talked about in regard to TLS upgrades and websockets, I do not want to invest in the current way of handling this too much time. -Stefan > Am 20.04.2016 um 05:35 schrieb William A Rowe Jr <wr...@rowe-clan.net>: > > On Tue, Apr 19, 2016 at 10:59 AM, Stefan Eissing > <stefan.eiss...@greenbytes.de> wrote: > > > Am 19.04.2016 um 17:47 schrieb William A Rowe Jr <wr...@rowe-clan.net>: > > > > I agree with your analysis, "h2" is not an upgrade candidate. > > > > "h2c" is an upgrade candidate. > > > > This isn't even an HTTP/2 issue (unless the working group reverses > > themselves > > on accepting Upgrade: h2 protocol switching), until we accept Upgrade: h2 we > > should be dropping h2 from the server Upgrade: response header. But do let > > us know what the wg feedback is. > > While I do not feel strongly about this feature, I'd like to add that the > "Upgrade: h2" is sent out as that very mechanism is available to a client. > And I do not feel strongly because I do not know of a client that might be > able to use it. It is just the result of a sane software architecture that > this has become visible. > > We would probably not be talking about this if some Javascript client > implementation had not consciously decided to freak out on *any* Upgrade: > header from the server. > > If http-wg thinks that it should not be visible, I'll add the extra 'if' to > our implementation. > > Skimming the responses, they just keep getting more and more amusing, and > shining a candle to the absurdity of keeping this non-sequitur request > response. > > Could you go ahead and add that conditional? > > We still haven't determined if the "reply Upgrade: once, then pretend we > didn't" > is valid HTTP/1.1, which I read that it is not. Need to come back to that > topic. > > Cheers, > > Bill
