nghttp2 with
apps and have nghttp in the $PATH...
//Stefan
> Am 17.11.2015 um 18:08 schrieb Jim Jagielski :
>
> No issues under CentOS...
>
>> On Nov 17, 2015, at 11:28 AM, Stefan Eissing
>> wrote:
>>
>> That's cheating...
>>
>> I'll
his works for everyone. Sorry for the initial confusion.
//Stefan
> Am 17.11.2015 um 18:08 schrieb Jim Jagielski :
>
> No issues under CentOS...
>
>> On Nov 17, 2015, at 11:28 AM, Stefan Eissing
>> wrote:
>>
>> That's cheating...
>>
&
> Am 19.11.2015 um 13:58 schrieb Yann Ylavic :
>
> On Thu, Nov 19, 2015 at 1:26 PM, Yann Ylavic wrote:
>>
>> Am I right to assume "H2Direct off" is the defaut now (in 2.5-dev and
>> upcoming 2.4.18, trunk docs seem not updated, and [1] suggests this is
>> from r1708107)?
>
> Hmm, then r1709587
I can check that change on the test setup and meditate about the docs phrasing
a bit...
> Am 19.11.2015 um 14:11 schrieb Yann Ylavic :
>
> On Thu, Nov 19, 2015 at 2:04 PM, Stefan Eissing
> wrote:
>>>
>>> Hmm, then r1709587 swithed it back to "H2Direct on for
+1 for lowercasing and pls backport, since it just arrived as is in 2.4.x, i
think.
> Am 20.11.2015 um 00:24 schrieb William A Rowe Jr :
>
> It wouldn't hurt to change this though, the tokens are generally represented
> in lowercase, and this could avoid case folding I suppose.
>
> How often d
Bert,
interesting and nice to see the progress. You probably could use priorities for
ordering, especially when using the stream dependencies. I am not certain,
however, if this will give you totally deterministic behavior. If stream B
depends on A, usually A will be sent out before B. However,
Most of this is discussed here:
https://httpwg.github.io/specs/rfc7540.html#HttpHeaders
Basically HTTP/2 defines its own connection properties, so several things which
are announced/controlled
by Connection: and other headers do not apply to HTTP/2 connections. So, the
"Connection:" header itse
Changes with Apache 2.5.0
>> *) mod_ssl: For the "SSLStaplingReturnResponderErrors off" case, make sure
>> to only staple responses with certificate status "good". [Kaspar Brand]
>>
>> + *) mod_http2: incoming trailers (headers after request body) ar
TP/2. A request or response
>containing uppercase header field names MUST be treated as
>malformed
>
>
>
>> On Nov 20, 2015, at 10:44 AM, Stefan Eissing
>> wrote:
>>
>> Most of this is discussed here:
>> https://httpwg.github.io/specs/r
Great! I try finish up the http2 stuff until Thursday as I will be unavailable
next week. But everything looks good so far from my end.
> Am 24.11.2015 um 20:09 schrieb Jim Jagielski :
>
> Just a head's up: I intend to T&R 2.4.18 around
> Nov 30th...
implementation under certain configuration is probably
the least that you'd want.
//Stefan
> Am 25.11.2015 um 03:10 schrieb Bert Huijben :
>
>> -Original Message-
>> From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
>> Sent: vrijdag 20 n
With the latest checkin into 2.4.x mod_http2 has everything I want for the
2.4.18 release. Tests work for me here on OS X and Ubuntu, so I hope this will
be fine.
Tomorrow I hopefully will find the time to make a blog about the upcoming
changes in 2.4.18 re HTTP/2 and Apache httpd. Make some pe
I am not really here, but...
the window updates are sent out via update_window(), line 1001,
h2_session.c. If you do not see any window updates with a client, it may
be that the server app you called does not read its input. I have
several test cases with uploads and they work with nghttp and
Ok, thanks. I think I have an idea of what's happening:
- on short request bodies, window updates get omitted and gives a shrinking
connection window
- the window size of the connection itself should be at max Value right from
the start
I won't be able to do anything about it until later this we
Please find with r1717641 version 1.0.9-DEV of mod_http2 in trunk and
branches/2.4.x
that fixes the issue of streams with smallish inputs and lost WINDOW_UPDATEs.
Please report back if this works for you. I have another time slot on Friday
where I can follow up on it. Thanks.
//Stefan
I put it on my TODO for friday, maybe I can conf/ifdef around it without too
much pain.
> Am 02.12.2015 um 23:16 schrieb William A Rowe Jr :
>
>> On Wed, Dec 2, 2015 at 3:06 PM, Reindl Harald wrote:
>>
>>> Am 02.12.2015 um 21:53 schrieb William A Rowe Jr:
>>> It seems nghttp2 1.2.1 is no long
That is unfortunate. I added a test case which reproduced window exhaustion
before I fixed it. What sort of requests do still miss window updates?
content-length? response codes?
thx.
Am 04.12.2015 um 02:36 schrieb Bert Huijben :
>> -Original Message-
>> From: St
mod_http2 in /trunk now checks for a minimum nghttp2 version of 1.2.1 and
#ifdefs code accordingly. Will backport to 2.4.x later together with other
changes.
> Am 04.12.2015 um 09:19 schrieb William A Rowe Jr :
>
> On Wed, Dec 2, 2015 at 5:24 PM, Stefan Eissing
> wrote:
> I pu
oduce the hanger.
//Stefan
> Am 04.12.2015 um 10:50 schrieb Bert Huijben :
>
>> -Original Message-
>> From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
>> Sent: vrijdag 4 december 2015 10:18
>> To: dev@httpd.apache.org
>> Subject: Re: No H2 Wind
you see? some data would be helpful here.
> Am 04.12.2015 um 18:42 schrieb Bert Huijben :
>
>
>
>> -Original Message-----
>> From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
>> Sent: vrijdag 4 december 2015 16:23
>> To: dev@httpd.apache.org
> Am 04.12.2015 um 20:51 schrieb Jan Ehrhardt :
>
> Stefan Eissing in gmane.comp.apache.devel (Fri, 4 Dec 2015 16:23:19
> +0100):
>> If you find the time, the lastest v1.0.10 mod_http2 in 2.4.x sets the
>> connection window to max which addresses for me the window st
I can certainly try more scenarios. The ones there in the tests reflect the
problems I have seen and verify the fixes I did.
If you have a h2load scenario that reproduces what you see, that could be very
helpful. Alternatively, what would I have to do to run your test on my machine?
> Am 04.12.
ect: RE: No H2 Window updates! (Probably a Serf issue!)
>>
>>
>>
>>> -Original Message-
>>> From: Bert Huijben [mailto:b...@qqmail.nl]
>>> Sent: vrijdag 4 december 2015 21:45
>>> To: dev@httpd.apache.org
>>> Su
Excellent! I have one proposed backport regarding ssl vars and slave
connections. If someone finds the time to look at it, that'd be great. It makes
http2 work better with var checks for HTTPS in .htaccess files.
> Am 05.12.2015 um 22:42 schrieb Jim Jagielski :
>
> With the latest patches, I th
Jan, thanks for tracking this down to the duplicate headers. I will look into
it.
Just to be sure I got everything right: you tested against the mod_h2 github
versions?
> Am 06.12.2015 um 07:53 schrieb Jan Ehrhardt :
>
> Jan Ehrhardt in gmane.comp.apache.devel (Sun, 06 Dec 2015 05:47:43 +0100)
, 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
>>> into it.
>>>
>>> Just to be sure I got everything right: you tested agains
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):
&
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...
equest(new))) {
> 83750 fielding ap_die(access_status, new);
> 83750 fielding return NULL;
> 83750 fielding }
>
> That's some ancient mojo there :)
>
>
> On Mon, Dec 7, 2015 at 6:46 AM, Stefan Eissing
> wrote:
> I think I just
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
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/
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
.
When writing the current code, I wanted the common tasks in core. But if that
needs to vary, we need to shift that.
> Am 07.12.2015 um 21:39 schrieb Stefan Eissing :
>
> There can be no 100 after a 101. After a 101, the downstream speaks the new
> protocol, immediately.
>
>
.12.2015 um 03:50 schrieb William A Rowe Jr :
>
> 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 an
> 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 wrote:
> >>
> >> On Tue, Dec 8, 2015 at 1:07 AM, Yann Ylavic wrote:
> >> >
> >
> 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 with a very short
>> OP
> 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
sed scheme?
Anything I missed?
PS. Re 5: with change 1+4, a TLS upgrade switcher could install an output
filter, return and have it being processed normally. The output filter would
then send the 101 and do the TLS handshake. Would that work?
> Am 08.12.2015 um 10:42 schrieb Stefan Eissing
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 [mailto:stefan.eiss...
ben :
>
>
>
>> -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
> 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. (correct,
> 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
>>>>
>>>>
> 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
>>>>
delaying
2.4.18 at this point and rather give us time to change it later, so it works
for everyone.
//Stefan
> Am 08.12.2015 um 13:46 schrieb Bert Huijben :
>
>
>
>> -Original Message-----
>> From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
>> Se
> 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 times.
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
>> Date: Tue Dec 8 13:30:30 2015
>> Ne
+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 2:30 PM, wrote:
> > Author: ylavic
> >
> 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
>
> Agreed, as spelled out
+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 deferring any upgrade changes
> >
> > Ag
For the next 2.4 release, I would like to add scoreboard support to mod_http2.
There are several options for doing so and I would like your feedback on which
route we should take. I try to outline what options I see:
A) Make mod_http2 workers general MPM workers. They would then become
part of
> Am 09.12.2015 um 19:06 schrieb William A Rowe Jr :
>
> I think I know where this author was misguided...
>
> On Dec 9, 2015 11:19, "William A Rowe Jr" wrote:
> >
> > And then I'm reading a really nonsensical comment in this FAQ...
> >
> > https://http2.github.io/faq/#implementation-questions
> Am 10.12.2015 um 02:07 schrieb William A Rowe Jr :
>
> There is a case to be made for the h2c to also be an 'early' upgrade decision,
> AIUI (correct me if I'm wrong Stefan) the mod_http2 module sees a request,
> grabs ahold of the network in the main request thread, and then 're-processes'
> t
Given all the input on this thread, I arrive at the following pseudo code:
1. Post Read Request Hook:
if (Upgrade: request header present) {
collect protocol proposals;
ps = protocol with highest preference from proposals;
if (ps && ps !=
+1: 14.04.1-Ubuntu SMP, gcc 4.8.4
worker, event, prefork
> Am 10.12.2015 um 14:57 schrieb Mike Rumph :
>
> Question below:
>
> On 12/10/2015 2:46 AM, Stefan Eissing wrote:
>> int xxx_switch(conn_rec *c, request_rec *r, server_rec *s,
>> const char *protocol, int phase)
>> {
&
Jacob, thanks for the code! I will let this and my pseudo code stew over the
weekend and then probably next week start the changes to upgrade handling.
//Stefan
> Am 10.12.2015 um 23:18 schrieb Jacob Champion :
>
> Okay, I finally have actual code to share. This is the original experimental
>
> Am 11.12.2015 um 02:22 schrieb Yann Ylavic :
>
> On Thu, Dec 10, 2015 at 11:46 AM, Stefan Eissing
> wrote:
>> Given all the input on this thread, I arrive at the following pseudo code:
>
> Thanks for _compiling_ this thread, quite exhaustive :)
Code often says more
The "slowly growing" part is certainly not good. For 2.4.18, my main concern
was stability and some important new features. I had a look at memory
consumption but could not find anything that explained the growth well.
Definitely needs more attention in the future...
> Am 10.12.2015 um 10:25 sc
> Am 11.12.2015 um 14:55 schrieb Yann Ylavic :
>
> Hi Stefan,
>
> On Fri, Dec 11, 2015 at 1:57 PM, wrote:
>> Author: icing
>> Date: Fri Dec 11 12:57:32 2015
>> New Revision: 1719403
>>
>> URL: http://svn.apache.org/viewvc?rev=1719403&view=rev
>> Log:
>> fixed window update on chunked uploads,
Thanks for RMing, Jim!
> Am 11.12.2015 um 23:23 schrieb Jim Jagielski :
>
> With more than the required 3 +1 (binding) votes, I call
> the VOTE closed with the result that the VOTE PASSES.
>
> I will start moving the artifacts so the mirrors can collect
> them over the weekend.
>
>> On Dec 8, 2
You're certain it's only loaded once?
> Am 14.12.2015 um 14:12 schrieb jean-frederic clere :
>
>
I just committed a change in mod_http2 that will return idle connections back
to the mpm, expecting to be invoked again when new data arrives. I learned
quite something about event (have not looked much at motorz yet) and am
thinking about improvements. If knowledgeable people could give me a ha
I would like to expose some HTTP/2 properties, for example "HTTP2=on|off"
similar to what mod_ssl does with HTTPS and other SSL variables. Current
implementation does not look like something to repeat, at first glance, but
maybe it's the only way...
The optional function ssl_is_https is used:
-
> Am 15.12.2015 um 17:58 schrieb Graham Leggett :
>
> On 15 Dec 2015, at 5:44 PM, Stefan Eissing
> wrote:
>
>> However, there is another state in HTTP/2 processing, where a BLOCK_READ is
>> performed: flow control on streaming out responses. Basically, the client
> Am 16.12.2015 um 15:31 schrieb Eric Covener :
>
> On Wed, Dec 16, 2015 at 6:40 AM, Stefan Eissing
> wrote:
>> So, the least work and most 2.4.x compatible way for mod_http2 is to mimmic
>> the mod_ssl way. http2_is_http2() and http2_var_lookup(), optional.
chrieb William A Rowe Jr :
>
> On Wed, Dec 16, 2015 at 5:40 AM, Stefan Eissing
> wrote:
>
> Subprocesses get their environment via r->subprocess_env, filled via the
> "fixups" hook. This is the usual way how we involve modules in request
> processing. But,
Gone in r1722074. Was added by the original import.
> Am 28.12.2015 um 18:01 schrieb Eric Covener :
>
> On Mon, Dec 28, 2015 at 11:46 AM, Jacob Perkins
> wrote:
>> We found a .gitignore file ./modules/http2 that is removing the MakeFile
>> from the sources. Was this supposed to be merged in? It’
That feeds into the Grand Solution to make h2 workers part of the MPM. Not sure
how to approach that.
The common way today is that master connections do not return from
run_connection if they are busy handling requests. If that takes longer than
H2Timeout to produce results, it may happen neve
Done, thanks!
> Am 04.01.2016 um 16:59 schrieb Yann Ylavic :
>
> On Wed, Dec 30, 2015 at 9:17 PM, Stefan Eissing
> wrote:
>> That feeds into the Grand Solution to make h2 workers part of the MPM. Not
>> sure how to approach that.
>
> How about calling apr_thread_join() in cleanup_zombies?
Thanks, Yann. Those are leftovers from an earlier age and it's good that you
spotted those. Might explain some people complaining about loss of server
threads / workers after some time if h2 session shutdown waits on a lock not
released that way.
> Am 04.01.2016 um 16:57 schrieb Yann Ylavic :
>
To the Knowledgable out there: how can I detect that the server is gracefully
restarting?
Backlground is that HTTP/2
1. is sometimes in the state of being IDLE, but unable to return to the MPM,
*could* however terminate the HTTP2 session.
2. HTTP2 sessions can be brought down by first announc
Thanks, I will investigate tomorrow and report back.
> Am 05.01.2016 um 17:26 schrieb William A Rowe Jr :
>
> On Tue, Jan 5, 2016 at 8:24 AM, Eric Covener wrote:
> On Tue, Jan 5, 2016 at 9:21 AM, Stefan Eissing
> wrote:
> > To the Knowledgable out there: how can I dete
> Am 09.01.2016 um 19:18 schrieb Jim Jagielski :
>
> Here is the general concept:
>
> The health check itself is done via mod_watchdog, and uses
> its callback impl. Each worker will have its own check interval,
> which can be changed via the new balancer member directives
> (hcinterval=, hcfail
> Am 18.01.2016 um 22:05 schrieb Christophe JAILLET
> :
>
> Le 18/01/2016 17:22, ic...@apache.org a écrit :
>> Author: icing
>> Date: Mon Jan 18 16:22:57 2016
>> New Revision: 1725301
>>
>> URL: http://svn.apache.org/viewvc?rev=1725301&view=rev
>> Log:
>> mod_http2 v1.2.2 from trunk
>
> I gues
A questions for the knowledgable SSL people here:
I experimented with setting socket timeouts to 1 second during HTTP/2's
keepalive reading and closing the connection after n such TIMEUP returns. That
works nicely on cleartext connections, but https:// return APR_EOF on reads
after the first A
I'd like some feedback to a small scoreboard/mod_status patch. It makes the
following changes:
- new method ap_update_child_status_from_server(ap_sb_handle_t *sbh, int
status, conn_rec *c, server_rec *s); in the API
- mod_ssl uses that to announce servers selected by TLS servername *before* the
Thanks, Yann! First tests show that that change does not help, though. Will
experiment with tweaking ssl_engine_io some...
> Am 20.01.2016 um 21:50 schrieb Yann Ylavic :
>
> On Tue, Jan 19, 2016 at 4:52 PM, Stefan Eissing
> wrote:
>>
>> I experimented with setting soc
Unexpected errors discard the brigade */
> Am 20.01.2016 um 21:50 schrieb Yann Ylavic :
>
> On Tue, Jan 19, 2016 at 4:52 PM, Stefan Eissing
> wrote:
>>
>> I experimented with setting socket timeouts to 1 second during
>> HTTP/2's keepalive reading and closing th
Jacob,
> Am 21.01.2016 um 00:19 schrieb Jacob Champion :
>
> Stefan,
>
> (I'm coming at this from more of a user's perspective than a code reviewer's.)
>
> On 01/20/2016 08:26 AM, Stefan Eissing wrote:
>> - mod_status introduces a new columne
investigate deeper on my own. Maybe needless fears on my
> side.
>
> Regards
>
> Rüdiger
>
>> -Ursprüngliche Nachricht-
>> Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
>> Gesendet: Donnerstag, 21. Januar 2016 11:52
>> An: dev@htt
> Am 21.01.2016 um 17:48 schrieb Jim Jagielski :
>
> Where are we with this? Trunk uses this. Should a backport
> proposal be done for 2.4??
+1
Ah, of course, just a moment...
> Am 21.01.2016 um 17:54 schrieb Jim Jagielski :
>
> Not seeing a mmn bump... ?
>
>> On Jan 21, 2016, at 11:36 AM, ic...@apache.org wrote:
>>
>> Author: icing
>> Date: Thu Jan 21 16:36:33 2016
>> New Revision: 1726009
>>
>> URL: http://svn.apache.org/viewvc?rev=
With the timeout behaviour of SSL reads fixed, I am making another attempt at
have http/2 connections behave properly in async MPMs, e.g. event. One thing
for that necessary as change in server is the hook to send a last GOAWAY frame
before the connection is closed. Not sending it seems to confu
> Am 22.01.2016 um 15:16 schrieb Eric Covener :
>
> On Fri, Jan 22, 2016 at 9:12 AM, Stefan Eissing
> wrote:
>> With the timeout behaviour of SSL reads fixed, I am making another attempt
>> at have http/2 connections behave properly in async MPMs, e.g. event. One
>
it...
Cheers,
Stefan
> Am 22.01.2016 um 16:13 schrieb Jim Jagielski :
>
> +1
>
>> On Jan 22, 2016, at 9:17 AM, Stefan Eissing
>> wrote:
>>
>>
>>> Am 22.01.2016 um 15:16 schrieb Eric Covener :
>>>
>>> On Fri, Jan 22, 2016 at 9:12 AM,
Interesting discussion. mod_http2 had similar issues to overcome and there
should be plenty of room for improvements...
> Am 27.01.2016 um 20:50 schrieb Ruediger Pluem :
> On 01/27/2016 12:46 PM, Yann Ylavic wrote:
>> On Wed, Jan 27, 2016 at 10:02 AM, Plüm, Rüdiger, Vodafone Group
>> wrote:
>>>
Congrats!
> Am 28.01.2016 um 18:10 schrieb Jim Jagielski :
>
> My proposed session for the Great Wide Open conference[1]
> about Apache httpd 2.4 has been accepted!
>
> 1. http://greatwideopen.org/schedule/
I would like to propose some additions to event that help me get rid of two
ugly hacks in mod_http2:
1. Initialization of slave connections
event registers on pre_connection hook and checks if c is a slave
(c->master) and if the connection state is either not there or the same as
master (poi
> Am 29.01.2016 um 13:55 schrieb Ruediger Pluem :
>
>
>
> On 01/27/2016 04:38 PM, Ruediger Pluem wrote:
>>
>>
>> On 01/27/2016 03:51 PM, ic...@apache.org wrote:
>>> Author: icing
>>> Date: Wed Jan 27 14:51:53 2016
>>> New Revision: 1727071
>>>
>>> URL: http://svn.apache.org/viewvc?rev=172707
the data connection/request aside the
> control connection. The right patch will improve both
> sets of dirty hacks :)
>
> Thanks for the proposal!
>
> Bill
>
> On Fri, Jan 29, 2016 at 7:01 AM, Stefan Eissing
> wrote:
> I would like to propose some additions to
Luca,
thanks for the long mail. I am looking forward to read the answers to your
questions, as I have *assumptions* about them, but am myself not certain.
> Am 01.02.2016 um 10:17 schrieb Luca Toscano :
>
> Hi Apache Devs!
>
> I am trying to understand if https://httpd.apache.org/docs/2.4/mod/
Interesting. I have an issue on github from someone who observes, sometimes, a
hanging
HTTP/2 connection, where mod_http2 calls ap_pass_brigade() with ~120KB which
never
returns. Client, after a while, closes its end of the connection. Connection
remains in CLOSE_WAIT.
Might this be related to
> Am 03.02.2016 um 11:47 schrieb Yann Ylavic :
>
> On Wed, Feb 3, 2016 at 11:38 AM, Stefan Eissing
> wrote:
>> Interesting. I have an issue on github from someone who observes, sometimes,
>> a hanging
>> HTTP/2 connection, where mod_http2 calls ap_pass_brigade
FYI: my write lockup is unrelated to yours and resides solely in my own code...
> Am 04.02.2016 um 10:08 schrieb Plüm, Rüdiger, Vodafone Group
> :
>
>
>
>> -Original Message-
>> From: Yann Ylavic [mailto:ylavic@gmail.com]
>> Sent: Donnerstag, 4. Februar 2016 10:04
>> To: httpd-dev
s 2c and I'll flip it?
>
> On Thu, Jan 21, 2016 at 11:57 AM, Stefan Eissing
> wrote:
>> Ah, of course, just a moment...
>>
>>> Am 21.01.2016 um 17:54 schrieb Jim Jagielski :
>>>
>>> Not seeing a mmn bump... ?
>>>
>>>> On Ja
FYI: I just checked in a very experimental mod_proxy_http2 that registers on
h2:// and h2c:// proxy URLs. I did this naming to have the module totally
separate from mod_proxy_http, not wanting to make a mess. So a sample
configuration looks like:
BalancerMember "h2://t
> Am 09.02.2016 um 00:38 schrieb Gregg Smith :
>
>> On 2/8/2016 9:07 AM, Stefan Eissing wrote:
>> PS. I did not update Windows Makefiles. I feel bad.
>
> Don't, I need to play catch-up anyway :)
>
> Should this be in modules/proxy like all the rest of the mod
t 6:07 PM, Stefan Eissing
> wrote:
>>
>> One thing: the ssl_hostname that is used for SNI by the generic proxy utils
>> seems to get lost when the socket needs to reset and is then not available
>> on the next connect. That should affect mod_proxy_http as far as I c
Mon, Feb 8, 2016 at 6:07 PM, Stefan Eissing
> wrote:
>> FYI: I just checked in a very experimental mod_proxy_http2 that registers on
>> h2:// and h2c:// proxy URLs. I did this naming to have the module totally
>> separate from mod_proxy_http, not wanting to make a mess.
&
With the new renegotiate code, I get failures in trunk for my tests that expect
renegotiation to fail on slave connections. Rainer, not sure how this works
now. Can you have a look?
-Stefan
401 - 500 of 1658 matches
Mail list logo