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}
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
