Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)

2016-04-19 Thread William A Rowe Jr
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 : > > > > I agree with your analysis, "h2" is not an upgrade candidate. > > > > "h2c" is an upgrade candidate. > > > > This isn't

Re: Allow SSLProxy* config in context?

2016-04-19 Thread Yann Ylavic
On Fri, Apr 15, 2016 at 1:30 PM, Yann Ylavic wrote: > On Thu, Apr 14, 2016 at 9:57 AM, Yann Ylavic wrote: >> >> IIUC, the block is a per_dir context already, which can/could >> accept any directive provided their ap_check_cmd_context() allows it >>

Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)

2016-04-19 Thread William A Rowe Jr
On Tue, Apr 19, 2016 at 11:26 AM, William A Rowe Jr wrote: > On Tue, Apr 19, 2016 at 11:04 AM, Jacob Champion > wrote: > >> On 04/19/2016 08:47 AM, William A Rowe Jr wrote: >> > I agree with your analysis, "h2" is not an upgrade candidate. >> > >> >

Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)

2016-04-19 Thread William A Rowe Jr
On Tue, Apr 19, 2016 at 11:04 AM, Jacob Champion wrote: > On 04/19/2016 08:47 AM, William A Rowe Jr wrote: > > I agree with your analysis, "h2" is not an upgrade candidate. > > > > "h2c" is an upgrade candidate. > > Is an h2c upgrade allowed over an HTTP/1.1+TLS connection?

Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)

2016-04-19 Thread Jacob Champion
On 04/19/2016 08:47 AM, William A Rowe Jr wrote: > I agree with your analysis, "h2" is not an upgrade candidate. > > "h2c" is an upgrade candidate. Is an h2c upgrade allowed over an HTTP/1.1+TLS connection? 7540 seems to hint that it's not ("The 'h2c' string is reserved from the ALPN

Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)

2016-04-19 Thread Stefan Eissing
> Am 19.04.2016 um 17:47 schrieb William A Rowe Jr : > > 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

Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)

2016-04-19 Thread William A Rowe Jr
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:

bucket beams

2016-04-19 Thread Stefan Eissing
I wrote a small post about the new h2_bucket_beam feature in the latest mod_http2. https://icing.github.io/mod_h2/beams.html Basically it's my solution to apr_bucket transport across threads without buffer copy. It is almost completely h2 agnostic, so if someone else has that use case, we

Re: allow newlines in T_ESCAPE_LOGITEM?

2016-04-19 Thread Daniel Lescohier
Of course, if you use "reliable piped logging" then if you also write more than PIPE_BUF bytes (4kiB on Linux) in a log line, it's not guaranteed to be atomic. I have been thinking of how to work around that limit, by logging to an Apache Flume Thrift RPC port. But to avoid the 4kiB limit you'd

Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)

2016-04-19 Thread Michael Kaufmann
On Tue, Apr 19, 2016 at 8:57 AM, Michael Kaufmann wrote: Yes, you are right. But with the response header "Upgrade: h2", Apache is telling the client "you may send such a header" when in fact this is not allowed. Devils advocate: Apache is telling the client at the

Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)

2016-04-19 Thread Eric Covener
On Tue, Apr 19, 2016 at 8:57 AM, Michael Kaufmann wrote: > Yes, you are right. But with the response header "Upgrade: h2", Apache is > telling the client "you may send such a header" when in fact this is not > allowed. Devils advocate: Apache is telling the client at

Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)

2016-04-19 Thread Michael Kaufmann
On Tue, Apr 19, 2016 at 8:47 AM, Michael Kaufmann wrote: I think that this is wrong, because of this sentence in RFC 7540: A server MUST ignore an "h2" token in an Upgrade header field. Presence of a token with "h2" implies HTTP/2 over TLS, which is instead

Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)

2016-04-19 Thread Eric Covener
On Tue, Apr 19, 2016 at 8:47 AM, Michael Kaufmann wrote: > I think that this is wrong, because of this sentence in RFC 7540: >> >> A server MUST ignore an "h2" token in an Upgrade header field. Presence of >> a token with "h2" implies HTTP/2 over TLS, which is instead

"Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)

2016-04-19 Thread Michael Kaufmann
Hi, you may already know that HTTP/2 clients use ALPN to advertise support for HTTP/2 when TLS is used. The issue is this: When mod_http2 is enabled, Apache sends an "Upgrade: h2" response header to clients that have *not* advertised support for HTTP/2 (clients that speak only HTTP/1.x).

Re: file bucket, mmaps and SIGBUS

2016-04-19 Thread Stefan Eissing
> Am 19.04.2016 um 13:50 schrieb Yann Ylavic : > > Hi Stefan, > > On Tue, Apr 19, 2016 at 12:02 PM, Stefan Eissing > wrote: >> The reported problem of segmentation faults in mod_http2 during a graceful >> restart seems to boil down to the

file bucket, mmaps and SIGBUS

2016-04-19 Thread Stefan Eissing
The reported problem of segmentation faults in mod_http2 during a graceful restart seems to boil down to the fact that the document root is updated at the same time. On my OS X I can reproduce the SIGBUS when GETting the same 10 MB file again and again and copying over it. When I disable mmap