Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls

On Tue, Dec 8, 2015 at 3:07 AM, William A Rowe Jr wrote: >> >> The handler handling the first request has to read the body before the >> switch, eg. mod_proxy could forward the request without the client >> having switched to any other protocol. > > Whoa... First the handler

Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls

> Am 08.12.2015 um 01:58 schrieb William A Rowe Jr : > > On Mon, Dec 7, 2015 at 6:35 PM, Yann Ylavic wrote: > On Tue, Dec 8, 2015 at 1:27 AM, William A Rowe Jr wrote: > > On Mon, Dec 7, 2015 at 6:15 PM, Yann Ylavic

Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls

> Am 08.12.2015 um 10:48 schrieb Yann Ylavic : > > On Tue, Dec 8, 2015 at 3:07 AM, William A Rowe Jr wrote: > [...] > That's why I'd rather go with *not* honoring the Upgrade until a > request comes with no body. ++1

Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgradetls

> Am 07.12.2015 um 23:42 schrieb Jacob Champion : > > On 12/07/2015 02:30 PM, Bert Huijben wrote: >> Is this a h2 limitation or a mod_h2 limitation? >> >> If I would like h2c upgrade from Subversion without an additional >> request I would have to send the upgrade request

Re: Upgrade Summary

Bert, why can't you use h2c in direct mode? I assume you could store server support for this in the checkout meta data somewhere. //Stefan > Am 08.12.2015 um 11:30 schrieb Bert Huijben : > >> -Original Message- >> From: Stefan Eissing

Re: No H2 Window updates!

Eric Covener in gmane.comp.apache.devel (Mon, 7 Dec 2015 11:03:15 -0500): >On Mon, Dec 7, 2015 at 10:56 AM, Jan Ehrhardt wrote: >> Stefan Eissing in gmane.comp.apache.devel (Mon, 7 Dec 2015 13:58:07 >> +0100): >>>if you could find the time to verify that the duplicate headers

RE: Upgrade Summary

> -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 > > > > Am 08.12.2015 um 11:44 schrieb Yann Ylavic : > > > > On Tue, Dec 8, 2015 at

Upgrade Summary

Trying to summarize the status of the discussion and where the issues are with the current Upgrade implementation. Clarified: A. any 100 must be sent out *before* a 101 response B. request bodies are to be read in the original protocol, input filters like chunk can be used, indeed are

RE: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls

> -Original Message- > From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] > Sent: dinsdag 8 december 2015 10:25 > To: dev@httpd.apache.org > Subject: Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl > Upgrade tls > > > > Am 08.12.2015 um 01:58 schrieb William A Rowe Jr

Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgradetls

Bert, I do not understand. How do you want to make pipelining requests and protocol upgrades work together? I assume you talk about http pipelining where you send a second request before you receive the response for the first one... //Stefan > Am 08.12.2015 um 11:27 schrieb Bert Huijben

Re: Upgrade Summary

> Am 08.12.2015 um 12:18 schrieb Yann Ylavic : > > On Tue, Dec 8, 2015 at 11:54 AM, Stefan Eissing > wrote: >> >> Am 08.12.2015 um 11:44 schrieb Yann Ylavic : >>> >>> On Tue, Dec 8, 2015 at 11:07 AM, Stefan Eissing

RE: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgradetls

> -Original Message- > From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] > Sent: dinsdag 8 december 2015 10:43 > To: dev@httpd.apache.org > Subject: Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl > Upgradetls > If Apache accepts body lengths of up to 64KB (or

Re: Upgrade Summary

On Tue, Dec 8, 2015 at 11:54 AM, Stefan Eissing wrote: > > Am 08.12.2015 um 11:44 schrieb Yann Ylavic : >> >> On Tue, Dec 8, 2015 at 11:07 AM, Stefan Eissing >>> >>> PS. Re 5: with change 1+4, a TLS upgrade switcher could install an output >>>

RE: Upgrade Summary

> -Original Message- > From: Bert Huijben [mailto:b...@qqmail.nl] > Sent: dinsdag 8 december 2015 12:41 > To: dev@httpd.apache.org > Subject: RE: Upgrade Summary > > I don't think we should require all auth to happen on HTTP/1.1. If you want to go for equivalent implementations for

Re: Upgrade Summary

On Tue, Dec 8, 2015 at 12:18 PM, Yann Ylavic wrote: > On Tue, Dec 8, 2015 at 11:54 AM, Stefan Eissing > wrote: >> >> Am 08.12.2015 um 11:44 schrieb Yann Ylavic : >>> >>> On Tue, Dec 8, 2015 at 11:07 AM, Stefan Eissing

RE: Upgrade Summary

> -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 : > >> -Original Message- > >>

Re: Upgrade Summary

> Am 08.12.2015 um 14:08 schrieb Bert Huijben : > [...] > (I'm pretty sure we find new interesting proxy server scenarios :-( ) Not only that. Someone tested h2c against his server from various Tor exit nodes and got a failure rate > 10% because of network middle boxes... Fun

Re: Upgrade Summary

On Tue, Dec 8, 2015 at 11:07 AM, Stefan Eissing wrote: > Trying to summarize the status of the discussion and where the issues are > with the current Upgrade implementation. > > Clarified: > A. any 100 must be sent out *before* a 101 response > B. request bodies are

Re: Upgrade Summary

> Am 08.12.2015 um 11:44 schrieb Yann Ylavic : > > On Tue, Dec 8, 2015 at 11:07 AM, Stefan Eissing > wrote: >> [...] >> Open: >> 1. Protocols like Websocket need to take over the 101 sending themselves in >> the "switch protocol" phase.

Re: Upgrade Summary

> Am 08.12.2015 um 12:40 schrieb Bert Huijben : >> -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:

Re: 2.4.18 T

This will be happening today, afternoon, eastern time.

Re: Upgrade Summary

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 wrote: > I see. Delta-V goodies. > > My proposal therefore is: > - keep the upgrade/protocol

Re: Upgrade Summary

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

RE: Upgrade Summary

> -Original Message- > From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] > Sent: dinsdag 8 december 2015 11:07 > To: dev@httpd.apache.org > Subject: Upgrade Summary > > Trying to summarize the status of the discussion and where the issues are > with the current Upgrade

Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgradetls

On Tue, Dec 8, 2015 at 11:36 AM, Stefan Eissing wrote: > > I do not understand. How do you want to make pipelining requests and protocol > upgrades work together? I assume you talk about http pipelining where you > send a second request before you receive the

RE: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgradetls

> -Original Message- > From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] > Sent: dinsdag 8 december 2015 11:36 > To: dev@httpd.apache.org > Subject: Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl > Upgradetls > > Bert, > > I do not understand. How do you want to

RE: Upgrade Summary

> -Original Message- > From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] > Sent: dinsdag 8 december 2015 13:54 > To: dev@httpd.apache.org > Subject: Re: Upgrade Summary > > I see. Delta-V goodies. > > My proposal therefore is: > - keep the upgrade/protocol switch mechanism as is

Upgrade when !ap_request_has_body(r) only for 2.4.18? (was: svn commit: r1718595 - /httpd/httpd/branches/2.4.x/STATUS)

On Tue, Dec 8, 2015 at 2:30 PM, wrote: > Author: ylavic > Date: Tue Dec 8 13:30:30 2015 > New Revision: 1718595 > > URL: http://svn.apache.org/viewvc?rev=1718595=rev > Log: > Comment about ap_request_has_body() check for Upgrade. > > Modified: >

Re: Upgrade when !ap_request_has_body(r) only for 2.4.18? (was: svn commit: r1718595 - /httpd/httpd/branches/2.4.x/STATUS)

On Tue, Dec 8, 2015 at 2:37 PM, Yann Ylavic wrote: > On Tue, Dec 8, 2015 at 2:30 PM, wrote: >> Author: ylavic >> Date: Tue Dec 8 13:30:30 2015 >> New Revision: 1718595 >> >> URL: http://svn.apache.org/viewvc?rev=1718595=rev >> Log: >> Comment about

Re: Upgrade when !ap_request_has_body(r) only for 2.4.18? (was: svn commit: r1718595 - /httpd/httpd/branches/2.4.x/STATUS)

My only suggestion is that instead of willy-nilly suggesting patches that will be included in a release, that we actually take time to think of the correct patch, to implement it and TEST against it and only THEN have it backported. Please. We don't want to put out a semi-immediate 2.4.19

Re: Upgrade when !ap_request_has_body(r) only for 2.4.18? (was: svn commit: r1718595 - /httpd/httpd/branches/2.4.x/STATUS)

On Tue, Dec 8, 2015 at 7:37 AM, Yann Ylavic wrote: > On Tue, Dec 8, 2015 at 2:30 PM, wrote: > > Author: ylavic > > Date: Tue Dec 8 13:30:30 2015 > > New Revision: 1718595 > > > > URL: http://svn.apache.org/viewvc?rev=1718595=rev > > Log: > > Comment about

Re: Upgrade when !ap_request_has_body(r) only for 2.4.18? (was: svn commit: r1718595 - /httpd/httpd/branches/2.4.x/STATUS)

On Tue, Dec 8, 2015 at 8:34 AM, Stefan Eissing wrote: > +1 for deferring any upgrade changes that do not fix real issues - like > the one proposed for backport by Bill - to 2.4.19 > Agreed, as spelled out in my top-post, simplest path to 2.4.18, and these

Re: Upgrade when !ap_request_has_body(r) only for 2.4.18? (was: svn commit: r1718595 - /httpd/httpd/branches/2.4.x/STATUS)

With the current implementation, that seems wise. This restriction can be removed once the change we discussed with output filter/hook is working. > Am 08.12.2015 um 14:37 schrieb Yann Ylavic : > > On Tue, Dec 8, 2015 at 2:30 PM, wrote: >> Author: ylavic

Re: Upgrade when !ap_request_has_body(r) only for 2.4.18? (was: svn commit: r1718595 - /httpd/httpd/branches/2.4.x/STATUS)

> Am 08.12.2015 um 16:18 schrieb William A Rowe Jr : > > On Tue, Dec 8, 2015 at 8:34 AM, Stefan Eissing > wrote: > +1 for deferring any upgrade changes that do not fix real issues - like the > one proposed for backport by Bill - to 2.4.19 >

Re: Upgrade when !ap_request_has_body(r) only for 2.4.18? (was: svn commit: r1718595 - /httpd/httpd/branches/2.4.x/STATUS)

+1 for deferring any upgrade changes that do not fix real issues - like the one proposed for backport by Bill - to 2.4.19 > Am 08.12.2015 um 15:29 schrieb William A Rowe Jr : > > On Tue, Dec 8, 2015 at 7:37 AM, Yann Ylavic wrote: > On Tue, Dec 8, 2015 at

Re: Upgrade when !ap_request_has_body(r) only? (was: for 2.4.18)

On Tue, Dec 8, 2015 at 3:29 PM, William A Rowe Jr wrote: > On Tue, Dec 8, 2015 at 7:37 AM, Yann Ylavic wrote: >> >> E.g. (on top of r1717816): > > The problem is that you are disabling *advertising* of the protocol based > on the content of a request body.

Re: Upgrade when !ap_request_has_body(r) only for 2.4.18? (was: svn commit: r1718595 - /httpd/httpd/branches/2.4.x/STATUS)

On Tue, Dec 8, 2015 at 3:17 PM, Jim Jagielski wrote: > My only suggestion is that instead of willy-nilly suggesting > patches that will be included in a release, that we actually take > time to think of the correct patch, to implement it and TEST against > it and only THEN have

Re: Protocol API @bug warnings for 2.4.18?

+1 Fine by me. > Am 08.12.2015 um 16:31 schrieb William A Rowe Jr : > > On Tue, Dec 8, 2015 at 9:21 AM, Stefan Eissing > wrote: > > > On Tue, Dec 8, 2015 at 8:34 AM, Stefan Eissing > > wrote: > > +1 for

Re: Upgrade when !ap_request_has_body(r) only for 2.4.18? (was: svn commit: r1718595 - /httpd/httpd/branches/2.4.x/STATUS)

> On Dec 8, 2015, at 11:11 AM, Yann Ylavic wrote: > > On Tue, Dec 8, 2015 at 3:17 PM, Jim Jagielski wrote: >> My only suggestion is that instead of willy-nilly suggesting >> patches that will be included in a release, that we actually take >> time to

Protocol API @bug warnings for 2.4.18?

On Tue, Dec 8, 2015 at 9:21 AM, Stefan Eissing wrote: > > > On Tue, Dec 8, 2015 at 8:34 AM, Stefan Eissing < > stefan.eiss...@greenbytes.de> wrote: > > +1 for deferring any upgrade changes > > > > Agreed, as spelled out in my top-post, simplest path to 2.4.18, and

Re: Upgrade when !ap_request_has_body(r) only for 2.4.18? (was: svn commit: r1718595 - /httpd/httpd/branches/2.4.x/STATUS)

So what is current (r1718631) is likely what will be tagged and rolled and, assuming enuff +1s, released.

Re: Protocol API @bug warnings for 2.4.18?

On Tue, Dec 8, 2015 at 4:31 PM, William A Rowe Jr wrote: > On Tue, Dec 8, 2015 at 9:21 AM, Stefan Eissing > wrote: >> >> >> > On Tue, Dec 8, 2015 at 8:34 AM, Stefan Eissing >> > wrote: >> > +1 for deferring any

Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgradetls

On 12/08/2015 01:42 AM, Stefan Eissing wrote: If Apache accepts body lengths of up to 64KB (or something configurable) and some other server implements 8K and some third 1MB, how will that help design of a client that, for some reason, *wants* an upgrade to succeed? I don't disagree with your

[VOTE] Release Apache httpd 2.4.18 as GA

The pre-release test tarballs for Apache httpd 2.4.18 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.18 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72

Re: Upgrade Summary

On 12/08/2015 02:07 AM, Stefan Eissing wrote: C. if a protocol supports upgrade on request bodies is up to the protocol implementation and needs to be checked in the "propose" phase Only if the module's intent is to simply ignore upgrade requests if they have bodies. Other modules might

Re: On the Upgrade request body limit

On 12/08/2015 12:45 PM, Jim Jagielski wrote: Well We are not NGINX. We are also not Microsoft. We don't create HTTP response codes willy-nilly. We actually try to *honor* the actual specs. Yes, I agree 100%. :) Trust me, I've dealt with enough non-standard HTTP "extensions"; I'm not

On the Upgrade request body limit

I wrote this in response to Stefan's note on the zero-length request body limit for h2c Upgrades, then realized it would further fragment the (already massive) conversation, so here it is. Stefan wrote: It is possible, but difficult to do unless you can read the body and > set it aside

Re: On the Upgrade request body limit

Well We are not NGINX. We are also not Microsoft. We don't create HTTP response codes willy-nilly. We actually try to *honor* the actual specs. > On Dec 8, 2015, at 3:22 PM, Jacob Champion wrote: > > I wrote this in response to Stefan's note on the zero-length request

Re: On the Upgrade request body limit

On Tue, Dec 8, 2015 at 11:43 PM, William A Rowe Jr wrote: > On Tue, Dec 8, 2015 at 4:17 PM, Yann Ylavic wrote: >> >> Why any HTTP/1 response? If the Upgrade is accepted, ISTM that the >> response must be Upgraded, no? > > The server is always free to

Re: On the Upgrade request body limit

On Tue, Dec 8, 2015 at 11:00 PM, William A Rowe Jr wrote: > > Apache httpd server offers limits on the number > of incoming headers, the number of bytes in those headers, the number of > bytes in the request line, the length of the URI. The maximum request body > length.

Re: On the Upgrade request body limit

On Tue, Dec 8, 2015 at 4:17 PM, Yann Ylavic wrote: > On Tue, Dec 8, 2015 at 11:00 PM, William A Rowe Jr > wrote: > > > > Define complex, robust. Request (upgrade: somespec) -> 100 continue -> > > request body <- [ http/1.1 response | 101 - switching

Re: On the Upgrade request body limit

On 12/08/2015 03:01 PM, Yann Ylavic wrote: Jacob, On Tue, Dec 8, 2015 at 11:17 PM, Yann Ylavic wrote: As I read the RFC, the simple(st) case is: Request (upgrade: somespec) -> request body <- 101 (upgrade: somespec) <- new protocol response or read Wouldn't that work

Re: Upgrade Summary

On Tue, Dec 8, 2015 at 3:43 PM, Jacob Champion wrote: > On 12/08/2015 01:03 PM, Jacob Champion wrote: > >> - The module that won the proposal is given one last chance to check the >> incoming request and fail the upgrade with an immediate HTTP response. >> > > And to add to

Re: On the Upgrade request body limit

On 12/08/2015 02:00 PM, William A Rowe Jr wrote: Apache httpd server offers limits on the number of incoming headers, the number of bytes in those headers, the number of bytes in the request line, the length of the URI. The maximum request body length. This is just one more limit, but not an

Re: On the Upgrade request body limit

Jacob, On Tue, Dec 8, 2015 at 11:17 PM, Yann Ylavic wrote: > > As I read the RFC, the simple(st) case is: > Request (upgrade: somespec) -> request body <- 101 (upgrade: somespec) > <- new protocol response or read Wouldn't that work for the WebSocket case? If the new

Re: Upgrade Summary

> On Dec 8, 2015, at 2:07 AM, Stefan Eissing > wrote: > > Trying to summarize the status of the discussion and where the issues are > with the current Upgrade implementation. > > Clarified: > A. any 100 must be sent out *before* a 101 response > B. request bodies

Re: reverse proxy wishlist

On 12/03/2015 03:59 PM, Jim Jagielski wrote: > I put out a call on Twitter regarding this, but wanted to > close the loop here as well. > > What would *you* like to see as new features or enhancements > w/ mod_proxy, esp reverse proxy. I was thinking about some > sort of active backend

Re: reverse proxy wishlist

On 12/03/2015 07:39 PM, Houser, Rick wrote: > I would definitely expect to see a substantial improvement if the thread > reservation could be delayed until the response headers are fully received. That is something tricky you need to mix blocking and non-blocking of have a bunch (configurable)

Re: On the Upgrade request body limit

On Tue, Dec 8, 2015 at 11:00 PM, William A Rowe Jr wrote: > > Define complex, robust. Request (upgrade: somespec) -> 100 continue -> > request body <- [ http/1.1 response | 101 - switching protocols <- new > protocol response ]. As I read the RFC, the simple(st) case is:

Re: Upgrade Summary

On 12/08/2015 01:03 PM, Jacob Champion wrote: - The module that won the proposal is given one last chance to check the incoming request and fail the upgrade with an immediate HTTP response. And to add to this, for completeness: mod_websocket also needs to add any required headers (e.g.

Re: Upgrade Summary

On 12/08/2015 02:30 AM, Bert Huijben wrote: The TLS and H2C upgrades both begin in one form and end in a different form. Websockets are kind of different in that they require a bad request response in a specific case. I'm not sure in which protocol this error needs to be send though. For

Re: On the Upgrade request body limit

> On Dec 8, 2015, at 4:00 PM, Jacob Champion wrote: > > On 12/08/2015 12:45 PM, Jim Jagielski wrote: >> Well >> >> We are not NGINX. We are also not Microsoft. We don't create HTTP >> response codes willy-nilly. We actually try to *honor* the actual >> specs. > >

Re: On the Upgrade request body limit

On Tue, Dec 8, 2015 at 2:22 PM, Jacob Champion wrote: > I wrote this in response to Stefan's note on the zero-length request body > limit for h2c Upgrades, then realized it would further fragment the > (already massive) conversation, so here it is. > And I agree to keep