[
https://issues.apache.org/jira/browse/TS-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14121776#comment-14121776
]
Bryan Call commented on TS-3060:
--------------------------------
It would be better to respond with 408:
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.
A 504 is a timeout from the upstream server:
6.6.5. 504 Gateway Timeout
The 504 (Gateway Timeout) status code indicates that the server,
while acting as a gateway or proxy, did not receive a timely response
from an upstream server it needed to access in order to complete the
request.
source: http://tools.ietf.org/html/rfc7231#section-6.5.7
> Attempt to send back a HTTP status code (e.g 504) upon a transaction
> inactivity timeout
> ---------------------------------------------------------------------------------------
>
> Key: TS-3060
> URL: https://issues.apache.org/jira/browse/TS-3060
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Affects Versions: 4.0.2
> Reporter: Sudheer Vinukonda
> Fix For: sometime
>
>
> This bug is similar to TS-3054, but, on the client connection.
> Currently, when ATS sees a transaction inactivity timeout on the client
> connection, it just closes the connection and releases the resources. As long
> as the socket is still active, it might be better to attempt sending back a
> HTTP status code to the client. For example, the use case might be a client
> sending a POST request with content-length, but doesn't send the body. ATS
> times out and aborts the connection without notifying the client. Even
> though, the inactivity timeout might indicate that the client connection is
> "dead", it's possible that the body that the client sent was "lost" somewhere
> on the network before reaching ATS. It's possible that the status code
> response may never make it to the client for the same reasons, but,
> nevertheless, it's worth to give it a try.
> Some things to keep in mind are if the response headers have already been
> sent to the client, sending a status code is not possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
