> On Oct 8, 2015, at 7:59 AM, Graham Leggett wrote:
>
> On 08 Oct 2015, at 1:45 PM, Jim Jagielski wrote:
>
>> Yeah... it was 'always' foreseen that mod_h2/mod_http2 would provide
>> useful clues on how to make 2.6/3.0 better, especially w/ the idea of
>>
OK, found the bug. Seems an update to the lastest nghttp2 lib co-incided with
the checkin of your async filter changes. Everything is fine now.
At least I learned some more about core filters, cannot hurt. Thanks for the
help.
//Stefan
> Am 07.10.2015 um 18:40 schrieb Graham Leggett
On 07 Oct 2015, at 4:30 PM, Stefan Eissing wrote:
> In http2 land, the request happen on "pseudo" connections, connections
> properly created by ap_run_create_connection(), but with own filters of type
> AP_FTYPE_PROTOCOL and AP_FTYPE_NETWORK, registered by
On 08 Oct 2015, at 1:45 PM, Jim Jagielski wrote:
> Yeah... it was 'always' foreseen that mod_h2/mod_http2 would provide
> useful clues on how to make 2.6/3.0 better, especially w/ the idea of
> slave connections; basically, as you say, let the MPM make mod_http2's
> job easier
Graham,
I am very happy to get such feedback and start thinking about how to make the
http/2 integration tighter. As it is designed now, it was intended to fit into
a 2.4.x server which limited several design decisions and resulted in the
separate worker pool. Since HTTP/2 changes the
> Am 08.10.2015 um 13:53 schrieb Graham Leggett :
>
>> HTTP/2 on https:// connections, as reported by Firefox, is currently at ~30%
>> of requests.
>
> We need to make sure we haven’t made a step backwards in the core of the
> server. The event MPM solved the C10k problem
On 08 Oct 2015, at 1:23 PM, Stefan Eissing wrote:
> I am very happy to get such feedback and start thinking about how to make the
> http/2 integration tighter. As it is designed now, it was intended to fit
> into a 2.4.x server which limited several design
Yeah... it was 'always' foreseen that mod_h2/mod_http2 would provide
useful clues on how to make 2.6/3.0 better, especially w/ the idea of
slave connections; basically, as you say, let the MPM make mod_http2's
job easier by abstracting out a lot of the tricks that mod_http2 needs
to do to
On 07 Oct 2015, at 3:43 PM, Stefan Eissing wrote:
> Having just had time to look at which test cases fail: I see that static
> resources via HTTP/2 seem to work fine, however my tests with a proxy and or
> rewrite in between fail with high likelihood.
>
> Any
Having just had time to look at which test cases fail: I see that static
resources via HTTP/2 seem to work fine, however my tests with a proxy and or
rewrite in between fail with high likelihood.
Any hint at what exactly I might have to look for, any hint about what actually
has changed,
Hi Stefan,
On Wed, Oct 7, 2015 at 3:43 PM, Stefan Eissing
wrote:
> Having just had time to look at which test cases fail: I see that static
> resources via HTTP/2 seem to work fine, however my tests with a proxy and or
> rewrite in between fail with high
> Am 07.10.2015 um 16:09 schrieb Graham Leggett :
>
> On 07 Oct 2015, at 3:43 PM, Stefan Eissing
> wrote:
>
>> Having just had time to look at which test cases fail: I see that static
>> resources via HTTP/2 seem to work fine, however my tests
> Am 07.10.2015 um 17:55 schrieb Graham Leggett :
>
> On 07 Oct 2015, at 4:30 PM, Stefan Eissing
> wrote:
>> [...]
>> Due to the non-multithreadability of apr_buckets, no buckets are ever moved
>> across threads. non-meta buckets are read, meta
On 07 Oct 2015, at 4:30 PM, Stefan Eissing wrote:
>> Can you describe how cleanups occur in the http2 world?
>
> In http2 land, the request happen on "pseudo" connections, connections
> properly created by ap_run_create_connection(), but with own filters of type
On 07 Oct 2015, at 6:23 PM, Stefan Eissing wrote:
>> Can you explain "non-multithreadability of apr_buckets” in more detail? I
>> take it this is the problem with passing a bucket from one allocator to
>> another?
>>
>> If so then the copy makes more sense.
>
>
15 matches
Mail list logo