https://bz.apache.org/bugzilla/show_bug.cgi?id=57661
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661
--- Comment #13 from Malay ---
I posted PR 332 https://github.com/apache/tomcat/pull/332 with my
implementation. Please let me know if this is the right approach, I thought of
several ways to implement this and decided on this approach because
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661
--- Comment #12 from Michael Osipov ---
(In reply to Malay from comment #11)
> I took a closer look at my implementation and it is actually option (c):
> c) container sends it when an InputStream / Reader is first used
>
> The approach that I'
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661
--- Comment #11 from Malay ---
I took a closer look at my implementation and it is actually option (c):
c) container sends it when an InputStream / Reader is first used
The approach that I'm taking is to only send the '100 continue' response w
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661
--- Comment #10 from Michael Osipov ---
(In reply to Christopher Schultz from comment #9)
> Why send 100-continue if you don't expect to send a request entity? The
> whole point of 100-continue is to request permission from the server to send
>
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661
--- Comment #9 from Christopher Schultz ---
Why send 100-continue if you don't expect to send a request entity? The whole
point of 100-continue is to request permission from the server to send a
(usually large) request entity.
--
You are rece
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661
--- Comment #8 from Michael Osipov ---
Please note that state changing actions do not necessary require a body, e.g.,
DELETE or generic POST with command in the URL. If Tomcat would wait until
obtaining input this would completely defeat Expect
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661
--- Comment #7 from ma...@backblaze.com ---
(In reply to Mark Thomas from comment #5)
I ran into this recently and ended up implementing option (b) locally:
b) container sends it when an InputStream / Reader is obtained
I'd be happy to prepare
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661
--- Comment #6 from Michael Osipov ---
(In reply to Mark Thomas from comment #5)
> See https://github.com/eclipse-ee4j/servlet-api/issues/307 for a description
> of what other containers do.
>
> Options appear to be:
> a) container sends it af
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661
--- Comment #5 from Mark Thomas ---
See https://github.com/eclipse-ee4j/servlet-api/issues/307 for a description of
what other containers do.
Options appear to be:
a) container sends it after auth (current Tomcat behaviour)
b) container sends
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661
Michael Osipov changed:
What|Removed |Added
CC||micha...@apache.org
--
You are recei
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661
--- Comment #4 from Michael Osipov <1983-01...@gmx.net> ---
To add some additional information based on my findings in Tomcat 6.0.45:
As already described by Mark, Tomcat sends the negative reponse before a client
has completely uploaded his req
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661
--- Comment #3 from Tobias Oberlies ---
Sorry for the redundant comments.
I have an addition to my analysis in comment #1:
> ... (e.g. the Apache httpclient). These clients could
> send only headers plus the "Expect: 100-continue" and would th
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661
Tobias Oberlies changed:
What|Removed |Added
CC||tobias.oberl...@sap.com
--- Comment
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661
--- Comment #1 from Tobias Oberlies ---
It is unfortunate that Tomcat unconditionally send 100 CONTINUE
acknowledgements. (In Tomcat 7 this is triggered by the StandardContextValve.)
The "Expect: 100-continue" is important for clients that wan
15 matches
Mail list logo