Am 2020-02-18 um 23:43 schrieb Mark Thomas:
On 18/02/2020 19:47, Michael Osipov wrote:
Am 2020-02-18 um 20:28 schrieb Mark Thomas:

<snip/>

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?

Yes.

If you say this is also a limitation in the Servlet API, it is worth to
raise that as a clarification point?

Sure. It won't happen until at least Servlet 5.1 though. 5.0 is limited
to the javax -> jakarta rename and posisble some minor clean-up.

Can you raise this question please? I guess you are the one with the foo for that.

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.

Indeed.

I will pick this up next week and I'll see how I can add a comparsion list for both.

Michael

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to