[
https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14580573#comment-14580573
]
ASF GitHub Bot commented on TS-1125:
------------------------------------
Github user sudheerv commented on the pull request:
https://github.com/apache/trafficserver/pull/216#issuecomment-110774240
@ffcai is right about how the config <send_100_continue_response> works.
Basically, when enabled, ATS would send a dummy "100 CONT" to the clients on
receiving POST requests. Below's a clarification on why this feature was
needed/added (afaik) -
*) ATS core has bugs/limitations in the handling of "100 CONT" message
(apparently, ATS either stalls indefinitely on receiving the message from the
origin or relays it back to the client too late (after POST body) both of which
are not ideal from a client's perspective).
*) Some legacy clients always wait for a fixed duration before sending the
POST body, if a "100 CONT" is not received.
The solution to address both concerns above was to basically send a dummy
"100 CONT" from ATS and strip off the *Expect* header in the server request
(TS-1125).
In any case, even with the previous patch, sending of "100 CONT" was being
done in *HttpSM::state_send_server_request_header* which only means the origin
connection has been made but, not really after the origin gave a go-ahead to
send the POST body (there's no response from origin yet in that state, afaict).
{code}
The purpose of the 100 (Continue) status (see section 10.1.1) is to allow a
client that is sending a request message with a request body to determine if
the origin server is willing to accept the request (based on the request
headers) before the client sends the request body. In some cases, it might
either be inappropriate or highly inefficient for the client to send the body
if the server will reject the message without looking at the body.
{code}
> POST's with Expect: 100-continue are slowed by delayed 100 response.
> --------------------------------------------------------------------
>
> Key: TS-1125
> URL: https://issues.apache.org/jira/browse/TS-1125
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Affects Versions: 3.0.2
> Environment: TS 3.0.2 going to Apache 2.2 web server
> Reporter: William Bardwell
> Assignee: Bryan Call
> Priority: Minor
> Labels: yahoo
> Fix For: 5.0.0
>
> Attachments: TS-1125.diff, TS-1125.diff, ts1125.diff, ts1125.diff,
> ts1125.diff
>
>
> Sending a post like:
> POST / HTTP/1.1
> Host: www.example.com
> Content-Length: 10
> Expect: 100-continue
> directly to the web server immediately sends back:
> HTTP/1.1 100 Continue
> And then when the post data is sent, a status 200 response comes back.
> But when going through ATS the "HTTP/1.1 100 Continue" is not sent
> immediately, and instead is sent after the POST data has been received. This
> is legal, but it makes clients that are hoping for a 100 continue to wait a
> little while hoping to get that, ATS should forward that response through
> immediately.
> Note: I see curl using "Expect: 100-continue" with > 1024 bytes of post data,
> but web searching indicates that some Microsoft products also use it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
