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 even an HTTP/2 issue (unl
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
>> (we may need to declare a new PROXY_CONF).
>>
>
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.
>> >
>> > "h2c" is an upgrade candidate.
>>
>> Is an h2c
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? 7540 seems to
> hint t
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
identifier
> 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 switching), until we
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: re
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 coul
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 h
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 application
layer its proto
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 application
layer its pr
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 negotiated as
described in Section 3
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 negotiated as
>> described in
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).
> 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 fact that the document root is updated at
>> the same
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 fact that the document root is updated at
> the same time. On my OS X I can reproduce the SIGBUS when GETting the s
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 f
17 matches
Mail list logo
