On Thu, Oct 22, 2015 at 3:42 PM, Andy Wang wrote:
>
> Tested with the patch and looks good.
Not that much actually, the patch fails to consume the CRLFs, and
hence can end up in an infinite loop.
So I'm attaching a new one here (committed in trunk with a larger
scope, this version is for 2.4.x a
On 10/22/2015 10:31 AM, Andy Wang wrote:
On 10/22/2015 10:06 AM, Yann Ylavic wrote:
Does it make a difference with "AcceptFilter http none" configured?
It shouldn't, but since we are in the x-files...
I already had to do that. We have this weird scenario where when our
installer installs
On 22 Oct 2015, at 6:04 PM, Stefan Eissing wrote:
>> mod_ssl already worries about buffering on it’s own, there is no need to
>> recreate this functionality. Was this not working?
>
> As I wrote "it has other bucket patterns", which do not get optimized by the
> coalescing filter of mod_ssl.
On 22 Oct 2015, at 6:03 PM, Stefan Eissing wrote:
> This is all true and correct - as long as all this happens in a single
> thread. If you have multiple threads and create sub pools for each from a
> main pool, each and every create and destroy of these sub-pools, plus any
> action on the mai
On 22 Oct 2015, at 5:55 PM, Stefan Eissing wrote:
>> With the async filters this flow control is now made available to every
>> filter in the ap_filter_setaside_brigade() function. When mod_http2 handles
>> async filters you’ll get this flow control for free.
>
> No, it will not. The processin
On 22 Oct 2015, at 5:43 PM, Stefan Eissing wrote:
>> The blocking read breaks the spirit of the event MPM.
>>
>> In theory, as long as you enter the write completion state and then not
>> leave until your connection is done, this problem will go away.
>>
>> If you want to read instead of write
> Am 21.10.2015 um 16:48 schrieb Graham Leggett :
>
> On 21 Oct 2015, at 4:18 PM, Stefan Eissing
> wrote:
>
>> 7. The buckets passed down on the master connection are using another buffer
>> - when on https:// -
>> to influence the SSL record sizes on write. Another COPY is not nice, but
>>
> Am 21.10.2015 um 16:48 schrieb Graham Leggett :
>
> On 21 Oct 2015, at 4:18 PM, Stefan Eissing
> wrote:
>> 6. pool buckets are very tricky to optimize, as pool creation/destroy is not
>> thread-safe in general
>> and it depends on how the parent pools and their allocators are set up.
>> E
On 10/22/2015 10:52 AM, Andy Wang wrote:
On 10/22/2015 10:38 AM, Graham Leggett wrote:
On 22 Oct 2015, at 5:31 PM, Andy Wang wrote:
I already had to do that. We have this weird scenario where when our
installer installs httpd, httpd hangs. Packet captures show the
request arriving but n
> Am 21.10.2015 um 16:48 schrieb Graham Leggett :
>
> On 21 Oct 2015, at 4:18 PM, Stefan Eissing
> wrote:
> [...]
>> 3. The amount of buffered bytes should be more flexible per stream and
>> redistribute a maximum for
>> the whole session depending on load.
>> 4. mod_http2 needs a process wi
On 10/22/2015 10:38 AM, Graham Leggett wrote:
On 22 Oct 2015, at 5:31 PM, Andy Wang wrote:
I already had to do that. We have this weird scenario where when our installer
installs httpd, httpd hangs. Packet captures show the request arriving but no
ACK or any form of response.
If I kill
(I split these up, since answers touch on different topics):
> Am 21.10.2015 um 16:48 schrieb Graham Leggett :
>
> On 21 Oct 2015, at 4:18 PM, Stefan Eissing
> wrote:
>
>> How good does this mechanism work for mod_http2? On the one side it's the
>> same, on the other quite different.
>>
>>
On 22 Oct 2015, at 5:31 PM, Andy Wang wrote:
> I already had to do that. We have this weird scenario where when our
> installer installs httpd, httpd hangs. Packet captures show the request
> arriving but no ACK or any form of response.
>
> If I kill the installer process, the problem goes a
On 10/22/2015 10:06 AM, Yann Ylavic wrote:
Does it make a difference with "AcceptFilter http none" configured?
It shouldn't, but since we are in the x-files...
I already had to do that. We have this weird scenario where when our
installer installs httpd, httpd hangs. Packet captures show t
Does it make a difference with "AcceptFilter http none" configured?
It shouldn't, but since we are in the x-files...
On Thu, Oct 22, 2015 at 4:52 PM, Andy Wang wrote:
> So this is the problematic request:
> 02D0 6e 74 2d 54 79 70 65 3a 09 74 65 78 74 2f 70 6c nt-Type: .text/pl
> 02E0 6
So this is the problematic request:
02D0 6e 74 2d 54 79 70 65 3a 09 74 65 78 74 2f 70 6c nt-Type: .text/pl
02E0 61 69 6e 0d 0a 0d 0a 0a ain.
This is a "regular" request using HttpPRequester extension or just using
ncat or curl:
02D0 6e 74 2d 54 79 70
On Thu, Oct 22, 2015 at 8:42 AM, Andy Wang wrote:
>
> On 10/21/2015 10:01 AM, Andy Wang wrote:
>
> I will do that today.
>>>
>>> And thank you to Rudiger and yourself, and everyone else on the thread
>>> for all the help.
>>>
>>> I missed the trailing 0x0a in the different wireshark captures. I
On 10/21/2015 10:01 AM, Andy Wang wrote:
I will do that today.
And thank you to Rudiger and yourself, and everyone else on the thread
for all the help.
I missed the trailing 0x0a in the different wireshark captures. I was
trusting wireshark's http dissection rather than looking at the raw h
18 matches
Mail list logo
