[
https://issues.apache.org/jira/browse/TS-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3060:
----------------------------------
Description:
This bug is similar to TS-3054, but, on the client connection.
Currently, when ATS sees a transaction activity or 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.
was:
This bug is similar to TS-3054, but, on the client connection.
Currently, when ATS sees a transaction activity 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.
> Attempt to send back a HTTP status code (e.g 408) upon a transaction activity
> timeout from the client
> -----------------------------------------------------------------------------------------------------
>
> Key: TS-3060
> URL: https://issues.apache.org/jira/browse/TS-3060
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core, HTTP
> Affects Versions: 4.0.2
> Reporter: Sudheer Vinukonda
> Labels: yahoo
> Fix For: sometime
>
> Attachments: TS-3060.diff
>
>
> This bug is similar to TS-3054, but, on the client connection.
> Currently, when ATS sees a transaction activity or 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)
