[
https://issues.apache.org/jira/browse/TS-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840678#comment-13840678
]
Bryan Call commented on TS-2419:
--------------------------------
IRC conversation:
{code}
bcall: on 204's: Maybe related to chunking and/or content length? I.e. make
sure you have enough information to be sure you can reuse the KA connection
without client being confused about how much it has or should read
11:35
jkew left the room (quit: Quit: Leaving.).
11:35
zwoop
bcall: on the auth stuff: Don't we have some configurations related to this ?
bcall: e.g. what does proxy.config.http.cache.ignore_authentication do ?
11:39
bcall
I would have to look but I didn't see the config being used in the code I was
looking at
it might only use that options when it is trying to do a cache write - looking
more at it today
11:41
zwoop
ok
as for 204's, I'm ok for making that KA'able, with the caveat that you assure
that the client knows it's safe to do so. Look at some of other logic we have
there, such as the setting where we trust the content-length value.
i.e. allow 204's to be KA'able as long as we're certain about the content
length etc.
(the issue here is that we can stall clients if what the client expects and
what the client sees is not the same, and then the KA connection is in an
invalid state)
11:54
bcall
it doesn't seem like it stalls the client - since the request per con to the
client side doubles - meaning that more requests happened on that connection
we are doing a crazy amount of 204s
11:57
zwoop
bcall: I'm just saying your use of 204's might be ok, but that's not
necessarily true for all origins
11:57
zwoop
which is most likely why they have that in there
the lack of body together with a missing or wrong Content-Length: header could
probably cause havoc
11:58
bcall
this change only effects the client
11:58
zwoop
204's are empty docs right ?
11:58
bcall
11:58
yes
11:58
zwoop
client ?
the response comes from an oirgin, no ?
imagine this. Origin sends a 204 with a Content-Length: 1234
that will hang the client
11:58
bcall
yes, but we change the ka on the client connection
not on the server con
11:58
zwoop
right
that's a defense mechanism
to avoid hanging the client
12:00
bcall
it might be best to close the connection if we see chunking or content-length
from the origin
on a 204 response
12:01
zwoop
right
that's what I'm saying
{code}
> Don't close client connection when responding with a 204 and there is no body
> -----------------------------------------------------------------------------
>
> Key: TS-2419
> URL: https://issues.apache.org/jira/browse/TS-2419
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP
> Reporter: Bryan Call
> Fix For: 4.2.0
>
>
> Currently ATS closes the client connection when returning a 204. In
> production I saw a 2x the number of requests per connection when not closing
> the connection on a 204 response. It the patch below I only close the
> connection if it is chunked encoding or content length not equal to 0.
> patch so far, untested:
> {code}
> diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
> index 049e672..ad3bbfd 100644
> --- a/proxy/http/HttpTransact.cc
> +++ b/proxy/http/HttpTransact.cc
> @@ -6756,9 +6756,10 @@
> HttpTransact::handle_response_keep_alive_headers(State* s, HTTPVersion ver,
> HTTP
> } else if (HTTP_MAJOR(ver.m_version) == 0) { /* No K-A for 0.9 apps */
> ka_action = KA_DISABLED;
> }
> - // some systems hang until the connection closes when receiving a 204
> - // regardless of the K-A headers
> - else if (heads->status_get() == HTTP_STATUS_NO_CONTENT) {
> + else if (heads->status_get() == HTTP_STATUS_NO_CONTENT &&
> + (s->current.server->transfer_encoding != NO_TRANSFER_ENCODING ||
> s->hdr_info.request_content_length != 0)) {
> + // some systems hang until the connection closes when receiving a 204
> regardless of the K-A headers
> + // close if there is any body response from the origin
> ka_action = KA_CLOSE;
> } else {
> // Determine if we are going to send either a server-generated or
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
