[jira] [Updated] (TS-3049) SPDY requests returning 200 OK with empty body..
[
https://issues.apache.org/jira/browse/TS-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3049:
--
Attachment: (was: TS-3049.diff)
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
Labels: yahoo
Fix For: 5.1.0
Attachments: 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.3.4#6332)
[jira] [Updated] (TS-3049) SPDY requests returning 200 OK with empty body..
[
https://issues.apache.org/jira/browse/TS-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3049:
--
Attachment: TS-3049.diff
Updated the patch with the dechunking part in check_chunked() that was lost in
cleaning up
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
Labels: yahoo
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.3.4#6332)
[jira] [Updated] (TS-3049) SPDY requests returning 200 OK with empty body..
[
https://issues.apache.org/jira/browse/TS-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3049:
---
Labels: yahoo (was: )
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
Labels: yahoo
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.3.4#6332)
[jira] [Updated] (TS-3049) SPDY requests returning 200 OK with empty body..
[
https://issues.apache.org/jira/browse/TS-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3049:
--
Attachment: (was: TS-3049.diff)
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
Labels: yahoo
Fix For: 5.1.0
Attachments: 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.3.4#6332)
[jira] [Updated] (TS-3049) SPDY requests returning 200 OK with empty body..
[
https://issues.apache.org/jira/browse/TS-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3049:
--
Attachment: TS-3049.diff
restrict the response header/body duplication logic for non-spdy requests for
backward compatibility with 4.0.x versions. For spdy connections, the bytes
duplication results in confusing the client.
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
Labels: yahoo
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.3.4#6332)
[jira] [Updated] (TS-3049) SPDY requests returning 200 OK with empty body..
[
https://issues.apache.org/jira/browse/TS-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3049:
--
Attachment: (was: TS-3049.diff)
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
Labels: yahoo
Fix For: 5.1.0
Attachments: 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.3.4#6332)
[jira] [Updated] (TS-3049) SPDY requests returning 200 OK with empty body..
[
https://issues.apache.org/jira/browse/TS-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3049:
--
Attachment: TS-3049.diff
change the duplicate byte copy check to use TS_FETCH_FLAGS_STREAM instead of
NOT_INTERNAL_REQUEST
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
Labels: yahoo
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.3.4#6332)
[jira] [Updated] (TS-3049) SPDY requests returning 200 OK with empty body..
[
https://issues.apache.org/jira/browse/TS-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3049:
--
Attachment: TS-3049.diff
Attached is the patch that fixes FetchSM to handle Connection:Close header
correctly. Note that the bug is in FetchSM and may affect non-spdy connections
that use FetchSM as well.
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)
[jira] [Updated] (TS-3049) SPDY requests returning 200 OK with empty body..
[
https://issues.apache.org/jira/browse/TS-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3049:
--
Attachment: (was: TS-3049.diff)
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: 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)
[jira] [Updated] (TS-3049) SPDY requests returning 200 OK with empty body..
[
https://issues.apache.org/jira/browse/TS-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3049:
--
Attachment: TS-3049.diff
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: 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)
[jira] [Updated] (TS-3049) SPDY requests returning 200 OK with empty body..
[
https://issues.apache.org/jira/browse/TS-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3049:
--
Attachment: (was: TS-3049.diff)
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: 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)
[jira] [Updated] (TS-3049) SPDY requests returning 200 OK with empty body..
[
https://issues.apache.org/jira/browse/TS-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3049:
--
Attachment: TS-3049.diff
Update the flag from int64_t to int
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)
[jira] [Updated] (TS-3049) SPDY requests returning 200 OK with empty body..
[
https://issues.apache.org/jira/browse/TS-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3049:
--
Attachment: (was: TS-3049.diff)
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: 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)
[jira] [Updated] (TS-3049) SPDY requests returning 200 OK with empty body..
[
https://issues.apache.org/jira/browse/TS-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3049:
--
Attachment: TS-3049.diff
Updated check_connection_close() a little bit per [~amc]'s comments
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)
[jira] [Updated] (TS-3049) SPDY requests returning 200 OK with empty body..
[
https://issues.apache.org/jira/browse/TS-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3049:
--
Priority: Blocker (was: Major)
Affects Version/s: 5.0.1
Fix Version/s: 5.1.0
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
Priority: Blocker
Fix For: 5.1.0
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)
