[ 
https://issues.apache.org/jira/browse/TS-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160881#comment-14160881
 ] 

Sudheer Vinukonda commented on TS-3106:
---------------------------------------

[~briang] - A couple of notes from RFC 7231 that are may affect the 
decision/commit below (wrt the handling of status codes 408 and 413)

http://tools.ietf.org/html/rfc7231#section-6.5.7

6.5.7.  408 Request Timeout

   The 408 (Request Timeout) status code indicates that the server did
   not receive a complete request message within the time that it was
   prepared to wait.  A server SHOULD send the "close" connection option
   (Section 6.1 of [RFC7230]) in the response, since 408 implies that
   the server has decided to close the connection rather than continue
   waiting.  If the client has an outstanding request in transit, the
   client MAY repeat that request on a new connection.


http://tools.ietf.org/html/rfc7231#section-6.5.11

6.5.11.  413 Payload Too Large

   The 413 (Payload Too Large) status code indicates that the server is
   refusing to process a request because the request payload is larger
   than the server is willing or able to process.  The server MAY close
   the connection to prevent the client from continuing the request.

   If the condition is temporary, the server SHOULD generate a
   Retry-After header field to indicate that it is temporary and after
   what time the client MAY try again.

> 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)

Reply via email to