Am 2020-02-18 um 20:28 schrieb Mark Thomas:
On 18/02/2020 18:13, Michael Osipov wrote:
Am 2020-02-18 um 10:00 schrieb Mark Thomas:
On 17/02/2020 20:17, Michael Osipov wrote:
I have continued some tests on 8.5.51 with PUT requests and Expect: 100
continue header from HttpClient 5.0.
I have noticed that the very same code code fragment
What code fragment?
My bad, here it is:
Got it - I think. Let me re-phrase to see if I understand correctly.
You have a code fragment that issues a redirect.
The app submits a request with an header "Expect: 100-continue"
With the valve the sequence is:
- request
- redirect
- request
- 100 Continue
- response
With the filter the sequence is:
- request
- 100 Continue
- redirect (and body will be swallowed)
- request
- 100 Continue
- response
Exactly!
The questions is "Why the difference?" as the Filter is less efficient.
It ends up sending the body twice.
The answer is that Tomcat has to provide the "100 Continue" response
since there isn't a Servlet API for the app to do so. It does this as
the final act in the Context's pipeline (valve collection). That means
it happens after any Engine/Host/Context Valves you have configured but
before any Filters.
This enhancement request would help:
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661
but it would need to be made optional as it will add a delay to the
request processing in some circumstances.
Now this makes sense. This basically means that something like this [1]
cannot efficiently implemented w/o using a valve?
If you say this is also a limitation in the Servlet API, it is worth to
raise that as a clarification point?
It might be worth adding to docs/config/valve.html when a valve is more
approriate than a filter. This is clearly a pitfall for such a case.
Thanks for the clarification.
[1]
https://github.com/csviri/bodylimiter/blob/master/src/main/java/com/csviri/security/filter/bodylength/RequestMessageBodyLengthLimitFilter.java
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
