[
https://issues.apache.org/jira/browse/TS-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14116415#comment-14116415
]
Alan M. Carroll commented on TS-3049:
-------------------------------------
I finally got this to run locally. The patch doesn't make sense to me, unless
the copying is completely useless, in which case it shouldn't be done at all. I
do see that if the copy logic is as I would write it, the HTTP header shows up
in the content stream, which confuses the client. I must presume there is some
bad interaction with non-SPDY users of this API if the HTTP header is missing.
Then we would need either an additional flag (or different checking of the
current flags) to handle this difference, or have SPDY consume the HTTP header.
It seems clear from my testing that SPDY does not, itself, have any use for the
header as text in the stream and for SPDY the FetchSM should consume, not
preserve, the HTTP header.
> SPDY requests returning 200 OK with empty body..
> ------------------------------------------------
>
> Key: TS-3049
> URL: https://issues.apache.org/jira/browse/TS-3049
> Project: Traffic Server
> Issue Type: Bug
> Components: SPDY
> Affects Versions: 5.0.1
> Reporter: Sudheer Vinukonda
> Assignee: Brian Geffon
> Priority: Blocker
> Fix For: 5.1.0
>
> Attachments: TS-3049.diff, ts3049.pcap
>
>
> Ran into another issue in our production, where some SPDY requests were
> returning a valid response (200 OK), but, with no data (empty body).
> Below is a sample response:
> {code}
> t=688758 [st= 1] SPDY_SESSION_SYN_STREAM
> --> fin = true
> --> :host: ********
> :method: GET
> :path: /********.js
> :scheme: https
> :version: HTTP/1.1
> accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> accept-encoding: gzip,deflate
> accept-language: en-US,en;q=0.8
> cache-control: max-age=0
> cookie: [215 bytes were stripped]
> user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS
> X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.94
> Safari/537.36
> --> spdy_priority = 0
> --> stream_id = 1
> --> unidirectional = false
> t=688941 [st= 184] SPDY_SESSION_SYN_REPLY
> --> fin = false
> --> :status: 200 OK
> :version: HTTP/1.1
> accept-ranges: bytes
> age: 2
> cache-control: max-age=536112000
> content-encoding: gzip
> content-type: application/javascript
> date: Wed, 27 Aug 2014 23:39:53 GMT
> etag: "************************"
> expires: Sat, 05 Sep 2026 00:00:00 GMT
> last-modified: Wed, 27 Aug 2014 20:09:00 GMT
> server: ATS
> vary: Accept-Encoding
> via: HTTP/1.1 ********** (ApacheTrafficServer)
> x-ysws-request-id: **********
> x-ysws-visited-replicas: *********
> --> stream_id = 1
> t=688941 [st= 184] SPDY_SESSION_RECV_DATA
> --> fin = true
> --> size = 0
> --> stream_id = 1
> {code}
> Investigating further, it seems that the issue occurs, when the response from
> the origin is chunked. Debugging further, it looks like there's a bug in
> FetchSM - check_body_done() is broken for chunked encoding case.
> {code}
> bool
> FetchSM::check_body_done()
> {
> if (!check_chunked()) {
> if (resp_content_length == resp_recived_body_len +
> resp_reader->read_avail())
> return true;
> return false;
> }
> //
> // TODO: check whether the chunked body is done
> //
> return true;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
