https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #25 from Michael Osipov ---
Your explanation as well as the one on the code make perfectly sense. Thank
you!
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #24 from Yann Ylavic ---
> > * If no filter is in place the request will be passed as-is to the upstream
> > server, regardless whether it is with CL or chunked. Omitting CL (convert to
> > chunks) in this case would mean that a
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #23 from Yann Ylavic ---
> so to sum up:
> * If no filter is in place the request will be passed as-is to the upstream
> server, regardless whether it is with CL or chunked. Omitting CL (convert to
> chunks) in this case would mean
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #22 from Michael Osipov ---
(In reply to Yann Ylavic from comment #21)
> > For my understand: This only happens when a body modifying filter is in
> > place?!
>
> Right.
>
> > The filter requires the body to be present in a
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #21 from Yann Ylavic ---
> For my understand: This only happens when a body modifying filter is in
> place?!
Right.
> The filter requires the body to be present in a streaming fashion to
> perform its work, but "Expect:
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
Michael Osipov changed:
What|Removed |Added
CC||micha...@apache.org
--
You are
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #20 from Michael Osipov ---
For my understand: This only happens when a body modifying filter is in place?!
The filter requires the body to be present in a streaming fashion to perform
its work, but "Expect: 100-continue" operates
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #19 from Michael Osipov ---
I will have a look at this one too, I use this extensively.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
Graham Leggett changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #17 from Konstantin J. Chernov ---
> Could you please test it so that I can propose it for 2.4.x?
Looks like everything is working fine with v3. Thanks a lot! :)
> This may be what you want (since mod_security prevents
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #16 from Yann Ylavic ---
(In reply to Yann Ylavic from comment #15)
> Last option (I can think of) would be to convince the mod_security team to
> register their input filter as a protocol filter
They can't do that if their filter
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
Yann Ylavic changed:
What|Removed |Added
Attachment #36848|0 |1
is obsolete|
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #14 from Konstantin J. Chernov ---
Yann, unfortunately, it's not working :(
And it's not sending 100-Continue at all.
{code}
POST /service/endpoint HTTP/1.1
Host: host:port
Content-Type: text/plain
Content-Length: 1
Expect:
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
Yann Ylavic changed:
What|Removed |Added
Attachment #36838|0 |1
is obsolete|
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #12 from Konstantin J. Chernov ---
Yann, thank you very much for the detailed explanation and for the patch.
First of all, I finally reproduced the issue, and you were right that it was
caused by a per-request content filter.
And
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #11 from Yann Ylavic ---
I meant the first request in "ho1.txt", not the one from your "openssl
s_client".
This first request in "ho1.txt" is sent with both the header and body at the
same time (and by the way has no "Expect:
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #10 from Konstantin J. Chernov ---
Thanks, I'll try to recompile/install on test env tomorrow (and hopefully get
it into prod a week later) to see if anything changes.
I'll also try to reproduce this issue several times during the
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #9 from Yann Ylavic ---
Created attachment 36838
--> https://bz.apache.org/bugzilla/attachment.cgi?id=36838=edit
Send 100-continue (if needed) when spooling the request body
OK, mod_proxy blocks on spooling the request body
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #8 from Konstantin J. Chernov ---
No, that env var was not set (all setenv's used are in the first comment).
Isn't it supposed to be suppressing the 100-continue in response to the client?
In this case, the Apache is not making
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #7 from Yann Ylavic ---
Possibly you had some "SetEnv proxy-interim-response" policy configured on the
original attempt but not on the following ones?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #6 from Konstantin J. Chernov ---
Created attachment 36837
--> https://bz.apache.org/bugzilla/attachment.cgi?id=36837=edit
Fourth attempt (same settings as in ho1.txt, with ping parameter on BM) --
issue is not reproducing
Also
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #5 from Konstantin J. Chernov ---
Some magic is definitely happening here.
I was unable to reproduce this issue 12 hours after report. No changes were
made to tomcat or apache during this time.
I've added two attachments: ho1.txt
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #4 from Konstantin J. Chernov ---
Created attachment 36836
--> https://bz.apache.org/bugzilla/attachment.cgi?id=36836=edit
Third attempt (same log settings as in ho1.txt) - issue is not reproducing
--
You are receiving this
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #3 from Konstantin J. Chernov ---
Created attachment 36835
--> https://bz.apache.org/bugzilla/attachment.cgi?id=36835=edit
Second attempt (full trace7), issue is not reproducing
--
You are receiving this mail because:
You are
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #2 from Konstantin J. Chernov ---
Created attachment 36834
--> https://bz.apache.org/bugzilla/attachment.cgi?id=36834=edit
Original attempt, where the issue is shown
--
You are receiving this mail because:
You are the assignee
https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #1 from Yann Ylavic ---
Could you please provide the error_log of the transaction with LogLevel trace7?
--
You are receiving this mail because:
You are the assignee for the bug.
26 matches
Mail list logo
