I see. Delta-V goodies. My proposal therefore is: - keep the upgrade/protocol switch mechanism as is for the 2.4.18 release - make the agreed upon changes, including TLS upgrade and small content h2c upgrades for the next release
Since the mechanism is already out with 2.4.17, I see no sense in delaying 2.4.18 at this point and rather give us time to change it later, so it works for everyone. //Stefan > Am 08.12.2015 um 13:46 schrieb Bert Huijben <b...@qqmail.nl>: > > > >> -----Original Message----- >> From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] >> Sent: dinsdag 8 december 2015 13:22 >> To: dev@httpd.apache.org >> Subject: Re: Upgrade Summary >> >> >>> Am 08.12.2015 um 12:40 schrieb Bert Huijben <b...@qqmail.nl>: >>>> -----Original Message----- >>>> From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] >>>> Sent: dinsdag 8 december 2015 11:55 >>>> To: dev@httpd.apache.org >>>> Subject: Re: Upgrade Summary >>>>>> [...]3. When to do the upgrade dance: >>>>>> a post_read_request: upgrade precedes authentication >>>>> >>>>> Looks like it can't be RFC compliant, is it? >>>> >>>> I think it will not be, right. >>> >>> I read the spec as H2c and HTTP/1.1 are equivalent protocols. Handling >>> authentication *after* switching should work just like when not > switching. >> >> It does. We are only talking about upgrade. >> >>> As client I would like to switch as soon as possible, as at that point I > can >>> start multiple requests.. potentially with their own auth, using the > same or >>> different realms; or even different auth schemes. >> >> Again, your easiest choice is a direct h2c connection. The second easiest > is >> an initial OPTIONS * request without *request* body. The response may >> have >> any body length it wants. >> >> The options * will, as I understand it, not trigger any authentication. In >> another mail, you describe that you already send such a request as 1st > thing. >> But you said it has a body. What does that contain, I wonder? >> >> If you can live without that request body, we are all fine and have a > simple >> implementation. If we need to implement upgrades to h2c on some length >> request bodies, I personally do not have the time to do that right away >> among >> all other changes that are being discussed. At least not this week. >> >> So, what is so relevant about the OPTIONS request body, may I ask? > > I can't live without that request body. That would just add another request > to my handshake... the thing I'm trying to avoid. > > I'm guessing the body of that initial body is something like > [[ > <D:options xmlns:D="DAV:"> > <D:activity-collection-set /> > </D:options> > ]] > (content-type text/xml of course) > > And this request is mostly handled by mod_dav, and further annotated with > additional headers by mod_dav_svn. > > I can't just redesign DAV to optimize for http/2. If we had a timemachine, > we would have made other decisions. > > Would have been nice if we knew DELTA/V was never really implemented outside > Subversion. But now we have compatibility guarantees with older Subversion > clients/servers and other implementations that may use some of the features. > > Bert
