Totally agree. This is all post 2.4.21 with the "Header unset Upgrade"
available as workaround for 2.4.21.
> Am 16.06.2016 um 13:56 schrieb William A Rowe Jr :
>
>
> On Jun 16, 2016 3:30 AM, "Stefan Eissing"
> wrote:
> >
> > There are three
On Jun 16, 2016 3:30 AM, "Stefan Eissing"
wrote:
>
> There are three things to address, one core related and one HTTP/2
related:
>
> 1. The whole discussion arose, because there are clients that seriously
choke on
>*any* Upgrade: response header. No matter what
There are three things to address, one core related and one HTTP/2 related:
1. The whole discussion arose, because there are clients that seriously choke on
*any* Upgrade: response header. No matter what tokens it contains. Those
*can* now
be addressed via mod_header with a "Header unset
On 06/15/2016 01:32 PM, William A Rowe Jr wrote:
It seems to me that we -can- implement
Connection: Upgrade
Upgrade: h2
on a plaintext connection, which is simply shorthand for Upgrade:
TLS/1.x, HTTP/2
where the TLS connection *must* handshake with the ALPN token 'h2' (the 102
Switching
Rather than put statements into Roy's mouth... here are the relevant posts
which
were not disputed;
https://lists.w3.org/Archives/Public/ietf-http-wg/2016AprJun/0152.html
https://lists.w3.org/Archives/Public/ietf-http-wg/2016AprJun/0169.html
It seems to me that we -can- implement
Connection:
Zitat von Stefan Eissing :
Withdrawn the proposal in r1747668 after reading the comment from Roy again.
Apache is the only HTTP/2 server in this world that sends this strange
header. So omitting it would be the right thing to do.
Michael, since you know more
On Thu, Jun 9, 2016 at 3:52 PM, Michael Kaufmann
wrote:
>
> Note that "Suppress 'h2' announcements in Upgrade: header" has been
> inserted at the top of the STATUS file; it should probably be moved to the
> bottom of the 'Patches proposed' section.
>
Yea, that would be
Zitat von William A Rowe Jr :
Skimming the responses, they just keep getting more and more amusing, and
shining a candle to the absurdity of keeping this non-sequitur request
response.
Could you go ahead and add that conditional?
To all developers who participated in
> On Apr 20, 2016, at 4:29 AM, Stefan Eissing
> wrote:
>
>>
>> Am 20.04.2016 um 13:16 schrieb Yann Ylavic :
>>
>> On Wed, Apr 20, 2016 at 1:09 PM, Yann Ylavic wrote:
>>> On Wed, Apr 20, 2016 at 11:25 AM, Stefan Eissing
Yes, you are correct. Had not covered that test in my test suite...
Fixed in r1740119.
Thanks!
-Stefan
> Am 20.04.2016 um 13:24 schrieb Michael Kaufmann :
>
>> Done in r1740075.
>>
>
> I think that commit introduced a small bug, because the "for" loop is left
>
> Am 20.04.2016 um 13:16 schrieb Yann Ylavic :
>
> On Wed, Apr 20, 2016 at 1:09 PM, Yann Ylavic wrote:
>> On Wed, Apr 20, 2016 at 11:25 AM, Stefan Eissing
>> wrote:
>>> Done in r1740075.
>>>
>>> I was thinking of a
Done in r1740075.
I think that commit introduced a small bug, because the "for" loop is
left when "h2" is seen and "report_all" is false. There may be other
protocols that are more preferred than the current one.
Suggested change:
Index: server/protocol.c
On Wed, Apr 20, 2016 at 1:09 PM, Yann Ylavic wrote:
> On Wed, Apr 20, 2016 at 11:25 AM, Stefan Eissing
> wrote:
>> Done in r1740075.
>>
>> I was thinking of a nicer solution, but that involved inventing new hooks
>> which seems not worth it.
On Wed, Apr 20, 2016 at 11:25 AM, Stefan Eissing
wrote:
> Done in r1740075.
>
> I was thinking of a nicer solution, but that involved inventing new hooks
> which seems not worth it.
>
> Since this area of protocol negotiation has already been talked about in
>
Zitat von Stefan Eissing :
Done in r1740075.
I was thinking of a nicer solution, but that involved inventing new
hooks which seems not worth it.
Since this area of protocol negotiation has already been talked
about in regard to TLS upgrades and websockets, I
Done in r1740075.
I was thinking of a nicer solution, but that involved inventing new hooks which
seems not worth it.
Since this area of protocol negotiation has already been talked about in regard
to TLS upgrades and websockets, I do not want to invest in the current way of
handling this too
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
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.
>> >
>> >
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?
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
> 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
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:
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
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
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
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
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).
27 matches
Mail list logo