Wow, you have been busy in my sleep...
I will respond to individual messages later in my office. From what I got
overall:
- I completely agree with Yann, request bodies, 100 continue or not, are sent
using the original, pre-upgrade protocol, e.g. http/1.1
- until the body is read, 101 may be se
Sorry it took so long to respond to this earlier post, some of this might
have already been covered...
On Mon, Dec 7, 2015 at 1:03 PM, Stefan Eissing wrote:
>
>
Think about CORS restrictions and other stuff.
> - I think its the protocol handlers job to deal with any request body.
>
Strongly dis
On Mon, Dec 7, 2015 at 7:25 PM, Jacob Champion wrote:
> On 12/07/2015 03:49 PM, William A Rowe Jr wrote:
>
>> Just to confirm, the purpose of splitting this up into two separate
>> calls to the same function is solely to deal with "OPTIONS *", which
>> doesn't follow the same logical
On Dec 7, 2015 19:29, "Yann Ylavic" wrote:
>
> On Tue, Dec 8, 2015 at 1:58 AM, William A Rowe Jr
wrote:
> > On Mon, Dec 7, 2015 at 6:35 PM, Yann Ylavic
wrote:
> >>
> >> The body of the first request is never Upgraded, so why would we read
> >> it using the Upgraded protocol?
> >
> >
> > How do y
On 12/07/2015 03:49 PM, William A Rowe Jr wrote:
Just to confirm, the purpose of splitting this up into two separate
calls to the same function is solely to deal with "OPTIONS *", which
doesn't follow the same logical path in httpd? Or is there another
reason?
No, it is because t
On Tue, Dec 8, 2015 at 1:58 AM, William A Rowe Jr wrote:
> On Mon, Dec 7, 2015 at 6:35 PM, Yann Ylavic wrote:
>>
>> The body of the first request is never Upgraded, so why would we read
>> it using the Upgraded protocol?
>
>
> How do you mean? The RFC states we must read the request body
> (foll
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
> wrote:
> >>
> >> On Tue, Dec 8, 2015 at 1:07 AM, Yann Ylavic
> wrote:
> >> >
> >> > the body ought to be
> >> > set aside for any (r
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 wrote:
>>
>> On Tue, Dec 8, 2015 at 1:07 AM, Yann Ylavic wrote:
>> >
>> > the body ought to be
>> > set aside for any (relevant) TLS response (which needs the
>> > handshake...).
>>
>> Hmm, no
On Tue, Dec 8, 2015 at 1:13 AM, William A Rowe Jr wrote:
> On Mon, Dec 7, 2015 at 6:07 PM, Yann Ylavic wrote:
>>
>> The 100-continue case isn't a particular one IMHO, any Upgrade header
>> would be informative, not authoritative (not a 101 status).
>
> Not sure what you mean. If an Upgrade: requ
On Mon, Dec 7, 2015 at 6:15 PM, Yann Ylavic wrote:
> On Tue, Dec 8, 2015 at 1:07 AM, Yann Ylavic wrote:
> >
> > the body ought to be
> > set aside for any (relevant) TLS response (which needs the
> > handshake...).
>
> Hmm, no need to set aside, *unless* with must produce a response
> before the
On Tue, Dec 8, 2015 at 1:07 AM, Yann Ylavic wrote:
>
> the body ought to be
> set aside for any (relevant) TLS response (which needs the
> handshake...).
Hmm, no need to set aside, *unless* with must produce a response
before the entire body (and the handshake) is read.
But we'd better not Upgrad
On Mon, Dec 7, 2015 at 6:07 PM, Yann Ylavic wrote:
> On Mon, Dec 7, 2015 at 5:38 PM, William A Rowe Jr
> wrote:
> >
> > https://tools.ietf.org/html/rfc7230#section-6.7 makes things more
> > interesting, it calls out that 101-continue and the request body read
> > precedes the 101-switching proto
On Mon, Dec 7, 2015 at 6:05 PM, William A Rowe Jr
wrote:
> On Mon, Dec 7, 2015 at 2:54 PM, Stefan Eissing <
> stefan.eiss...@greenbytes.de> wrote:
>
>> ok, after some more thinking. if a tls+http/1.1 upgrade together with
>> Expect is indeed a use case, then, to make that work, sending the 101 ne
On Mon, Dec 7, 2015 at 2:54 PM, Stefan Eissing wrote:
> ok, after some more thinking. if a tls+http/1.1 upgrade together with
> Expect is indeed a use case, then, to make that work, sending the 101 needs
> to become the task of the switch protocol handler itself. Then the order in
> which interme
On Mon, Dec 7, 2015 at 5:38 PM, William A Rowe Jr wrote:
>
> https://tools.ietf.org/html/rfc7230#section-6.7 makes things more
> interesting, it calls out that 101-continue and the request body read
> precedes the 101-switching protocols. Not sure who decided that would be a
> good idea, sigh...
On Mon, Dec 7, 2015 at 5:21 PM, Jacob Champion wrote:
> On 12/07/2015 02:40 PM, William A Rowe Jr wrote:
>
>> Not "noise" at all... I'm imagining a mod_echo protocol example that
>> looks much like your use case...
>>
>> 1st call to core_upgrade_request in post_read_req hook, after setenvif
>> an
On Fri, Apr 24, 2015 at 2:04 AM, Niklas Edmundsson wrote:
>
> When trying to debug something else I stumbled across this code-snippet in
> modules/cache/mod_cache.c:
>
> errno = 0;
> x = control.max_age_value;
> if (errno) {
> x = dconf->defex;
> }
> else {
> x = x * MSEC_ONE_SEC;
> }
>
>
On 12/07/2015 02:40 PM, William A Rowe Jr wrote:
Not "noise" at all... I'm imagining a mod_echo protocol example that
looks much like your use case...
1st call to core_upgrade_request in post_read_req hook, after setenvif
and mod_headers processing... tls is ready, echo (or websocket) would
not
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 with a very short
OPTIONS request that has a body.
The HTTP/2 spec (RFC 7540, sec 3.2)
On Mon, Dec 7, 2015 at 4:10 PM, Jacob Champion wrote:
> On 12/07/2015 11:55 AM, Jacob Champion wrote:
>
>> > - moving things to post read sounds tempting, however I'm not sure if
>> we want to upgrade on non-authed request or not, for example. I am not
>> sure what else we do in post read, maybe
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 with a very short OPTIONS request that
has a body.
The way I read the spec that should be possible if both sides go through all
tho
On Mon, Dec 7, 2015 at 4:12 PM, William A Rowe Jr
wrote:
> On Mon, Dec 7, 2015 at 2:39 PM, Stefan Eissing <
> stefan.eiss...@greenbytes.de> wrote:
>
>> There can be no 100 after a 101. After a 101, the downstream speaks the
>> new protocol, immediately.
>>
>
> Right, and the new protocol is TLS/1
On Mon, Dec 7, 2015 at 2:39 PM, Stefan Eissing wrote:
> There can be no 100 after a 101. After a 101, the downstream speaks the
> new protocol, immediately.
>
Right, and the new protocol is TLS/1.x HTTP/1.1 in the mod_ssl case. What's
so confusing?
> Am 07.12.2015 um 21:29 schrieb William A
On 12/07/2015 11:55 AM, Jacob Champion wrote:
> - moving things to post read sounds tempting, however I'm not sure if
we want to upgrade on non-authed request or not, for example. I am not
sure what else we do in post read, maybe someone else has an opinion
about that. It certainly looks nicer i
On Dec 7, 2015 12:44 PM, "Stefan Eissing"
wrote:
>
> There can be no 100 after a 101. After a 101, the downstream speaks the
new protocol, immediately.
I suspect Bill is talking about the very specific case of an upgrade to
HTTP/1.1-over-TLS, in which case I think his proposed "101/100 handshake"
ok, after some more thinking. if a tls+http/1.1 upgrade together with Expect is
indeed a use case, then, to make that work, sending the 101 needs to become the
task of the switch protocol handler itself. Then the order in which
intermediate responses are sent depends on the switched protocol.
There can be no 100 after a 101. After a 101, the downstream speaks the new
protocol, immediately.
> Am 07.12.2015 um 21:29 schrieb William A Rowe Jr :
>
>> On Mon, Dec 7, 2015 at 2:15 PM, Jacob Champion wrote:
>> On Dec 7, 2015 8:43 AM, "William A Rowe Jr" wrote:
>> >
>> > https://tools.ietf
On Mon, Dec 7, 2015 at 2:15 PM, Jacob Champion wrote:
> On Dec 7, 2015 8:43 AM, "William A Rowe Jr" wrote:
> >
> > https://tools.ietf.org/html/rfc7230#section-6.7 makes things more
> interesting, it calls out that 101-continue and the request body read
> precedes the 101-switching protocols. No
On Dec 7, 2015 8:43 AM, "William A Rowe Jr" wrote:
>
> https://tools.ietf.org/html/rfc7230#section-6.7 makes things more
interesting, it calls out that 101-continue and the request body read
precedes the 101-switching protocols. Not sure who decided that would be a
good idea, sigh...
100-continu
Ugh, looks like I'm too slow on my work with the upgrade proposal hooks;
sorry I haven't been able to give in-depth feedback yet.
On Dec 7, 2015 11:09 AM, "Stefan Eissing"
wrote:
>
> Not at my machine to really check the runtime behaviour. Can do that
tomorrow. My thoughts so far:
>
> - the retur
h2 does not propose a switch if the request has a body.
As clarified on the http wg lists by the gurus there, when i asked, the
upgraded connection is in a mixed state after a 101. Any byte sent by the
server MUST be from the switched protocol, while the client needs to send the
body in HTTP/
Not at my machine to really check the runtime behaviour. Can do that tomorrow.
My thoughts so far:
- the return code was not checked intentionally. Once the 101 intermediate
response is sent, there is nothing core can do on the connection. It has been
switched to a protocol unknown to core. Fai
Von: William A Rowe Jr [mailto:wr...@rowe-clan.net]
Gesendet: Montag, 7. Dezember 2015 17:39
An: httpd
Betreff: Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls
https://tools.ietf.org/html/rfc7230#section-6.7 makes things more interesting,
it calls out that 101-continue a
Here's my thoughts to address this rather quickly for 2.4.18 to keep
ourselves on track; simply move the core protocol handling phase and
ap_switch_protocol action into the appropriate request processing phase,
address the fail-cases of the ap_switch_protocol exceptions that have
been overlooked so
Hi folks, sorry for the late interruption after we have already shipped
2.4.16, but there seems to be an issue that merits revisiting before the
2.4.16 API schema is widely adopted.
We seem to have misplaced the upgrade handler in the wrong hook. This is
easily shown by the fact that we had two d
Any internal redirect (such as his admin panel configuration). Serving
redirected static example content should be fine.
On Mon, Dec 7, 2015 at 10:19 AM, Stefan Eissing <
stefan.eiss...@greenbytes.de> wrote:
> Oh, I see. I ran into a special_special...
>
> How would I easily trigger this in a
Oh, I see. I ran into a special_special...
How would I easily trigger this in a test config?
> Am 07.12.2015 um 17:13 schrieb William A Rowe Jr :
>
> Within internal_internal_redirect;
>
> 83750 fielding /*
> 83750 fielding * XXX: hmm. This is because mod_setenvif and
> mod_u
Everything as it should be from mod_http2 for this.
//Stefan
PS. Had one changed to the mod_http2.xml and when I 'make docs'ed it, I got too
many changes locally. If someone with more knowledge than me on this would be
so kind...
Within internal_internal_redirect;
83750 fielding /*
83750 fielding * XXX: hmm. This is because mod_setenvif and
mod_unique_id really need
83750 fielding * to do their thing on internal redirects as well.
Perhaps this is a
83750 fielding * misnamed function.
8
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 are gone
>>in the current 2.4.x version, that'd be nice. Thanks!
>
> They are gone! Time to T&R 2.4
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 are gone
>in the current 2.4.x version, that'd be nice. Thanks!
They are gone! Time to T&R 2.4.18.
--
Jan
> On Dec 7, 2015, at 8:32 AM, Plüm, Rüdiger, Vodafone Group
> wrote:
> So I would go for a pragmatic approach with no sharp line. I guess we can
> bundle all balancers we deliver into one module. IMHO we wouldn't lose
> anything here
In this particular case, I would be +1. They are extremely
> -Ursprüngliche Nachricht-
> Von: Jim Jagielski [mailto:j...@jagunet.com]
> Gesendet: Montag, 7. Dezember 2015 14:09
> An: dev@httpd.apache.org
> Betreff: Re: reverse proxy wishlist
>
>
> > On Dec 5, 2015, at 9:30 PM, William A Rowe Jr
> wrote:
> >
> > On Sat, Dec 5, 2015 at 3:48 PM,
> On Dec 5, 2015, at 9:30 PM, William A Rowe Jr wrote:
>
> On Sat, Dec 5, 2015 at 3:48 PM, Jim Jagielski wrote:
>
> > On Dec 4, 2015, at 10:25 AM, William A Rowe Jr wrote:
> >
> > My observation was that that the mapped pages for 2-6 fundamental socache,
> > lbmethod or slotmem providers are
Jan,
if you could find the time to verify that the duplicate headers are gone in the
current 2.4.x version, that'd be nice. Thanks!
//Stefan
> Am 06.12.2015 um 07:21 schrieb Jan Ehrhardt :
>
> Stefan Eissing in gmane.comp.apache.devel (Fri, 4 Dec 2015 21:37:46
> +0100):
>>> 1.0.10 did not sol
I think I just found the problem:
I thought that h2_h2.c, line 678 was no longer needed. But under some, still
unknown, conditions the post_read_req hook is called twice. That makes a table
overlay twice which results in all headers_out be present twice.
I will remove the filter again before i
Can you retry w DEBUG level, to see if h2_response_trailers_filter()
is the issue?
> On Dec 6, 2015, at 6:33 AM, Jan Ehrhardt wrote:
>
> Stefan Eissing in gmane.comp.apache.devel (Sun, 6 Dec 2015 09:26:56 +0100):
>> Jan, thanks for tracking this down to the duplicate headers. I will look
>> in
47 matches
Mail list logo
