It used to be, I think, that all errors generated by ATS would prevent KA (force close). Did we change that? In either case, we should do this,
-- Leif > On Oct 3, 2014, at 12:00 PM, Brian Geffon (JIRA) <[email protected]> wrote: > > > [ > https://issues.apache.org/jira/browse/TS-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14158253#comment-14158253 > ] > > Brian Geffon commented on TS-3106: > ---------------------------------- > > Ok after talking with [~jacksontj] more, we both agree that the correct > behavior should be as follows: > > If you're serving an error page and the client sends any type of post body > which is indicated by a Content-Length or Transfer-Encoding: chunked, then > you need to do Connection: close, otherwise you can keep the connection alive. > > The current behavior in traffic server always keeps the connection alive > which will break the subsequent request because it uses the post body as the > method for the next request. The fix I'm thinking at this point is fairly > straight forward: > > > {code} > diff --git a/proxy/http/HttpSM.cc b/proxy/http/HttpSM.cc > index eadfe1d..818d5e8 100644 > --- a/proxy/http/HttpSM.cc > +++ b/proxy/http/HttpSM.cc > @@ -5863,6 +5863,11 @@ HttpSM::setup_100_continue_transfer() > void > HttpSM::setup_error_transfer() > { > + if ((t_state.hdr_info.request_content_length != 0 || > + t_state.client_info.transfer_encoding == > HttpTransact::CHUNKED_ENCODING)) { > + t_state.client_info.keep_alive = HTTP_NO_KEEPALIVE; > + } > + > if (t_state.internal_msg_buffer) { > // Since we need to send the error message, call the API > // function > {code} > >> ATS error responses do not flush request body >> --------------------------------------------- >> >> Key: TS-3106 >> URL: https://issues.apache.org/jira/browse/TS-3106 >> Project: Traffic Server >> Issue Type: Bug >> Reporter: Thomas Jackson >> Assignee: Brian Geffon >> Fix For: 5.2.0 >> >> >> If you send a request to ATS which causes an error page (no remap, blocked >> HTTP method, etc.) with a body, the following request will get a 403 >> response. This is due to ATS not flushing the request body of the first >> (failed) request. If you look in the logs for the second request you will >> see the URL as "POSBODY GET /" (or something similar). I can easily >> reproduce this on ATS 5. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.4#6332)
