If so, for 2.4.18 we should probably backport Bill's proposal in STATUS (r1717816), so that OPTIONS works as in 2.4.16...
On Tue, Dec 8, 2015 at 1:54 PM, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > 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 >
