You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Leif Hedstrom (JIRA)" <ji...@apache.org> on 2010/10/29 05:19:19 UTC
[jira] Created: (TS-500) Less draconian checks on Content-Length: +
Connection: close from origin
Less draconian checks on Content-Length: + Connection: close from origin
------------------------------------------------------------------------
Key: TS-500
URL: https://issues.apache.org/jira/browse/TS-500
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Leif Hedstrom
Fix For: 2.1.4
I think we should relax our checks on when to not trust the content-length header from Origin. We have a particularly troublesome case, which breaks youtube and possibly other streaming media sites:
////////////////////////////////////////////////////////
// this is the case that the origin server sent //
// us content length. Experience says that many //
// origin servers that do not support keep-alive //
// lie about the content length. to avoid truncation //
// of docuemnts from such server, if the server is //
// not keep-alive, we set to read until the server //
// closes the connection. We sent the maybe bogus //
// content length to the browser, and we will correct //
// the cache if it turnrd out that the servers lied. //
////////////////////////////////////////////////////////
if (incoming_response->presence(MIME_PRESENCE_CONTENT_LENGTH)) {
if (s->current.server->keep_alive == HTTP_NO_KEEPALIVE) {
s->hdr_info.trust_response_cl = false;
s->hdr_info.response_content_length = HTTP_UNDEFINED_CL
I'd like to suggest that we make this case optional (enabled / disabled via a records.config option). This would obviously require extensive testing, and probably should be enabled by default (i.e. preserver current behaviour).
>From the BIS RFC:
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-12#section-3.3
If the actual number of
octets sent in the message is more than the indicated Content-
Length, the recipient MUST only process the message-body up to
the field value's number of octets; the remainder of the message
MUST either be discarded or treated as the next message in a
pipeline.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-500) Less draconian checks on Content-Length: +
Connection: close from origin
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-500:
-----------------------------
Attachment: TS-500.diff
I accidentally made the commit against the wrong bug, so attaching the change here instead.
> Less draconian checks on Content-Length: + Connection: close from origin
> ------------------------------------------------------------------------
>
> Key: TS-500
> URL: https://issues.apache.org/jira/browse/TS-500
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Reporter: Leif Hedstrom
> Assignee: Leif Hedstrom
> Fix For: 2.1.4
>
> Attachments: TS-500.diff
>
>
> I think we should relax our checks on when to not trust the content-length header from Origin. We have a particularly troublesome case, which breaks youtube and possibly other streaming media sites:
> ////////////////////////////////////////////////////////
> // this is the case that the origin server sent //
> // us content length. Experience says that many //
> // origin servers that do not support keep-alive //
> // lie about the content length. to avoid truncation //
> // of docuemnts from such server, if the server is //
> // not keep-alive, we set to read until the server //
> // closes the connection. We sent the maybe bogus //
> // content length to the browser, and we will correct //
> // the cache if it turnrd out that the servers lied. //
> ////////////////////////////////////////////////////////
> if (incoming_response->presence(MIME_PRESENCE_CONTENT_LENGTH)) {
> if (s->current.server->keep_alive == HTTP_NO_KEEPALIVE) {
> s->hdr_info.trust_response_cl = false;
> s->hdr_info.response_content_length = HTTP_UNDEFINED_CL
> I'd like to suggest that we make this case optional (enabled / disabled via a records.config option). This would obviously require extensive testing, and probably should be enabled by default (i.e. preserver current behaviour).
> From the BIS RFC:
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-12#section-3.3
> If the actual number of
> octets sent in the message is more than the indicated Content-
> Length, the recipient MUST only process the message-body up to
> the field value's number of octets; the remainder of the message
> MUST either be discarded or treated as the next message in a
> pipeline.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-500) Less draconian checks on Content-Length:
+ Connection: close from origin
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12926161#action_12926161 ]
Leif Hedstrom commented on TS-500:
----------------------------------
I've done a bunch of tests with producing bad Content-Length: header, to see what we do. The origin is returning a response like
HTTP/1.1 200 OK
Date: Fri, 29 Oct 2010 03:33:14 GMT
Cache-Control: private
Content-Length: 8
Content-Type: text/html; charset=UTF-8
Hello world.
Hello world.
Hello world.
to which traffic_server will proxy the following back to the UA:
HTTP/1.1 200 OK
Date: Fri, 29 Oct 2010 03:33:14 GMT
Cache-Control: private
Content-Length: 8
Content-Type: text/html; charset=UTF-8
Age: 1021
Connection: keep-alive
Server: ATS/2.1.4-unstable
Hello wo
> Less draconian checks on Content-Length: + Connection: close from origin
> ------------------------------------------------------------------------
>
> Key: TS-500
> URL: https://issues.apache.org/jira/browse/TS-500
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Reporter: Leif Hedstrom
> Fix For: 2.1.4
>
>
> I think we should relax our checks on when to not trust the content-length header from Origin. We have a particularly troublesome case, which breaks youtube and possibly other streaming media sites:
> ////////////////////////////////////////////////////////
> // this is the case that the origin server sent //
> // us content length. Experience says that many //
> // origin servers that do not support keep-alive //
> // lie about the content length. to avoid truncation //
> // of docuemnts from such server, if the server is //
> // not keep-alive, we set to read until the server //
> // closes the connection. We sent the maybe bogus //
> // content length to the browser, and we will correct //
> // the cache if it turnrd out that the servers lied. //
> ////////////////////////////////////////////////////////
> if (incoming_response->presence(MIME_PRESENCE_CONTENT_LENGTH)) {
> if (s->current.server->keep_alive == HTTP_NO_KEEPALIVE) {
> s->hdr_info.trust_response_cl = false;
> s->hdr_info.response_content_length = HTTP_UNDEFINED_CL
> I'd like to suggest that we make this case optional (enabled / disabled via a records.config option). This would obviously require extensive testing, and probably should be enabled by default (i.e. preserver current behaviour).
> From the BIS RFC:
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-12#section-3.3
> If the actual number of
> octets sent in the message is more than the indicated Content-
> Length, the recipient MUST only process the message-body up to
> the field value's number of octets; the remainder of the message
> MUST either be discarded or treated as the next message in a
> pipeline.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-500) Less draconian checks on Content-Length:
+ Connection: close from origin
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12926164#action_12926164 ]
Leif Hedstrom commented on TS-500:
----------------------------------
I'll do some more tests tomorrow, to verify how we behave in all possible cases of CL: headers being too small, too large, vs connection: close / keep-alive, and how we deal with the connections to the origin (they should be closed and not reused if the CL header is incorrect, for sure).
But one thing is clear, as per the last comment, the current code violates the RFC in the response to the UA when we decide to ignore the CL: header. So, not only do we break sites like youtube with this code, it's in direct violation (in some cases).
> Less draconian checks on Content-Length: + Connection: close from origin
> ------------------------------------------------------------------------
>
> Key: TS-500
> URL: https://issues.apache.org/jira/browse/TS-500
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Reporter: Leif Hedstrom
> Fix For: 2.1.4
>
>
> I think we should relax our checks on when to not trust the content-length header from Origin. We have a particularly troublesome case, which breaks youtube and possibly other streaming media sites:
> ////////////////////////////////////////////////////////
> // this is the case that the origin server sent //
> // us content length. Experience says that many //
> // origin servers that do not support keep-alive //
> // lie about the content length. to avoid truncation //
> // of docuemnts from such server, if the server is //
> // not keep-alive, we set to read until the server //
> // closes the connection. We sent the maybe bogus //
> // content length to the browser, and we will correct //
> // the cache if it turnrd out that the servers lied. //
> ////////////////////////////////////////////////////////
> if (incoming_response->presence(MIME_PRESENCE_CONTENT_LENGTH)) {
> if (s->current.server->keep_alive == HTTP_NO_KEEPALIVE) {
> s->hdr_info.trust_response_cl = false;
> s->hdr_info.response_content_length = HTTP_UNDEFINED_CL
> I'd like to suggest that we make this case optional (enabled / disabled via a records.config option). This would obviously require extensive testing, and probably should be enabled by default (i.e. preserver current behaviour).
> From the BIS RFC:
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-12#section-3.3
> If the actual number of
> octets sent in the message is more than the indicated Content-
> Length, the recipient MUST only process the message-body up to
> the field value's number of octets; the remainder of the message
> MUST either be discarded or treated as the next message in a
> pipeline.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-500) Less draconian checks on Content-Length:
+ Connection: close from origin
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12927498#action_12927498 ]
Leif Hedstrom commented on TS-500:
----------------------------------
I'm still examining this "issue" and have found a number of interesting "problems" (separate bugs filed). I hope to have my analysis done today or tomorrow, and come up with a recommendation.
> Less draconian checks on Content-Length: + Connection: close from origin
> ------------------------------------------------------------------------
>
> Key: TS-500
> URL: https://issues.apache.org/jira/browse/TS-500
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Reporter: Leif Hedstrom
> Assignee: Leif Hedstrom
> Fix For: 2.1.4
>
>
> I think we should relax our checks on when to not trust the content-length header from Origin. We have a particularly troublesome case, which breaks youtube and possibly other streaming media sites:
> ////////////////////////////////////////////////////////
> // this is the case that the origin server sent //
> // us content length. Experience says that many //
> // origin servers that do not support keep-alive //
> // lie about the content length. to avoid truncation //
> // of docuemnts from such server, if the server is //
> // not keep-alive, we set to read until the server //
> // closes the connection. We sent the maybe bogus //
> // content length to the browser, and we will correct //
> // the cache if it turnrd out that the servers lied. //
> ////////////////////////////////////////////////////////
> if (incoming_response->presence(MIME_PRESENCE_CONTENT_LENGTH)) {
> if (s->current.server->keep_alive == HTTP_NO_KEEPALIVE) {
> s->hdr_info.trust_response_cl = false;
> s->hdr_info.response_content_length = HTTP_UNDEFINED_CL
> I'd like to suggest that we make this case optional (enabled / disabled via a records.config option). This would obviously require extensive testing, and probably should be enabled by default (i.e. preserver current behaviour).
> From the BIS RFC:
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-12#section-3.3
> If the actual number of
> octets sent in the message is more than the indicated Content-
> Length, the recipient MUST only process the message-body up to
> the field value's number of octets; the remainder of the message
> MUST either be discarded or treated as the next message in a
> pipeline.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-500) Less draconian checks on Content-Length:
+ Connection: close from origin
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12929630#action_12929630 ]
Leif Hedstrom commented on TS-500:
----------------------------------
I also tested cacheability of the bogus responses, and I see no difference with or without removing this check. There is in fact a case, where we are maybe cachiing something that shouldn't be cached, but that's a separate bug. A response with a CL: header which is less than the received body is still cached, with the Content-Length: size body preserved (i.e. truncated). I know the "truncation" is correct, but unsure if such a response is cacheable.
> Less draconian checks on Content-Length: + Connection: close from origin
> ------------------------------------------------------------------------
>
> Key: TS-500
> URL: https://issues.apache.org/jira/browse/TS-500
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Reporter: Leif Hedstrom
> Assignee: Leif Hedstrom
> Fix For: 2.1.4
>
>
> I think we should relax our checks on when to not trust the content-length header from Origin. We have a particularly troublesome case, which breaks youtube and possibly other streaming media sites:
> ////////////////////////////////////////////////////////
> // this is the case that the origin server sent //
> // us content length. Experience says that many //
> // origin servers that do not support keep-alive //
> // lie about the content length. to avoid truncation //
> // of docuemnts from such server, if the server is //
> // not keep-alive, we set to read until the server //
> // closes the connection. We sent the maybe bogus //
> // content length to the browser, and we will correct //
> // the cache if it turnrd out that the servers lied. //
> ////////////////////////////////////////////////////////
> if (incoming_response->presence(MIME_PRESENCE_CONTENT_LENGTH)) {
> if (s->current.server->keep_alive == HTTP_NO_KEEPALIVE) {
> s->hdr_info.trust_response_cl = false;
> s->hdr_info.response_content_length = HTTP_UNDEFINED_CL
> I'd like to suggest that we make this case optional (enabled / disabled via a records.config option). This would obviously require extensive testing, and probably should be enabled by default (i.e. preserver current behaviour).
> From the BIS RFC:
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-12#section-3.3
> If the actual number of
> octets sent in the message is more than the indicated Content-
> Length, the recipient MUST only process the message-body up to
> the field value's number of octets; the remainder of the message
> MUST either be discarded or treated as the next message in a
> pipeline.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TS-500) Less draconian checks on Content-Length:
+ Connection: close from origin
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom reassigned TS-500:
--------------------------------
Assignee: Leif Hedstrom
> Less draconian checks on Content-Length: + Connection: close from origin
> ------------------------------------------------------------------------
>
> Key: TS-500
> URL: https://issues.apache.org/jira/browse/TS-500
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Reporter: Leif Hedstrom
> Assignee: Leif Hedstrom
> Fix For: 2.1.4
>
>
> I think we should relax our checks on when to not trust the content-length header from Origin. We have a particularly troublesome case, which breaks youtube and possibly other streaming media sites:
> ////////////////////////////////////////////////////////
> // this is the case that the origin server sent //
> // us content length. Experience says that many //
> // origin servers that do not support keep-alive //
> // lie about the content length. to avoid truncation //
> // of docuemnts from such server, if the server is //
> // not keep-alive, we set to read until the server //
> // closes the connection. We sent the maybe bogus //
> // content length to the browser, and we will correct //
> // the cache if it turnrd out that the servers lied. //
> ////////////////////////////////////////////////////////
> if (incoming_response->presence(MIME_PRESENCE_CONTENT_LENGTH)) {
> if (s->current.server->keep_alive == HTTP_NO_KEEPALIVE) {
> s->hdr_info.trust_response_cl = false;
> s->hdr_info.response_content_length = HTTP_UNDEFINED_CL
> I'd like to suggest that we make this case optional (enabled / disabled via a records.config option). This would obviously require extensive testing, and probably should be enabled by default (i.e. preserver current behaviour).
> From the BIS RFC:
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-12#section-3.3
> If the actual number of
> octets sent in the message is more than the indicated Content-
> Length, the recipient MUST only process the message-body up to
> the field value's number of octets; the remainder of the message
> MUST either be discarded or treated as the next message in a
> pipeline.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-500) Less draconian checks on Content-Length:
+ Connection: close from origin
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12926162#action_12926162 ]
Leif Hedstrom commented on TS-500:
----------------------------------
However, if I add a Connection: close header from the origin, to trigger the code path above and turn the response into a Chunked response, we actually end up returning the entire body from the origin (which seems to be in violation with the RFC):
HTTP/1.1 200 OK
Date: Fri, 29 Oct 2010 03:33:14 GMT
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Age: 1098
Transfer-Encoding: chunked
Connection: keep-alive
Server: ATS/2.1.4-unstable
Hello world.
Hello world.
Hello world.
This would be an argument for actually removing this check entirely I think, or at least make it disabled by default?
> Less draconian checks on Content-Length: + Connection: close from origin
> ------------------------------------------------------------------------
>
> Key: TS-500
> URL: https://issues.apache.org/jira/browse/TS-500
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Reporter: Leif Hedstrom
> Fix For: 2.1.4
>
>
> I think we should relax our checks on when to not trust the content-length header from Origin. We have a particularly troublesome case, which breaks youtube and possibly other streaming media sites:
> ////////////////////////////////////////////////////////
> // this is the case that the origin server sent //
> // us content length. Experience says that many //
> // origin servers that do not support keep-alive //
> // lie about the content length. to avoid truncation //
> // of docuemnts from such server, if the server is //
> // not keep-alive, we set to read until the server //
> // closes the connection. We sent the maybe bogus //
> // content length to the browser, and we will correct //
> // the cache if it turnrd out that the servers lied. //
> ////////////////////////////////////////////////////////
> if (incoming_response->presence(MIME_PRESENCE_CONTENT_LENGTH)) {
> if (s->current.server->keep_alive == HTTP_NO_KEEPALIVE) {
> s->hdr_info.trust_response_cl = false;
> s->hdr_info.response_content_length = HTTP_UNDEFINED_CL
> I'd like to suggest that we make this case optional (enabled / disabled via a records.config option). This would obviously require extensive testing, and probably should be enabled by default (i.e. preserver current behaviour).
> From the BIS RFC:
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-12#section-3.3
> If the actual number of
> octets sent in the message is more than the indicated Content-
> Length, the recipient MUST only process the message-body up to
> the field value's number of octets; the remainder of the message
> MUST either be discarded or treated as the next message in a
> pipeline.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-500) Less draconian checks on Content-Length:
+ Connection: close from origin
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12929450#action_12929450 ]
Leif Hedstrom commented on TS-500:
----------------------------------
I've examined this a bit more, and in all cases, we do the correct thing and never reuse an origin server if there was a "mismatch" in expected body length vs what was seen. In those cases, we close the origin connection immediately. This is a good thing.
In the current code, there's one scenario where the "client" connection can hang around until either we (TS) or the client times out. This can happen if the Content-Length: header indicates more bytes in the body than what we actually received and proxied, *and* if there is no "Connection: close" header for HTTP/1.1 (basically, we are allowed to do keep-alive to the origin, the behaviour with HTTP/1.0 is slightly different).
I tried eliminating the "offending" check, that makes it possible to trust Content-Length: header even if the server sends a Connection: close. This works very similar to the current behaviour with keep-alive connections. The main difference is that where for a keep-alive connection to the origin, the client will "hang" for the duration of the timeout
proxy.config.http.transaction_no_activity_timeout_in
while in the (new) behaviour for Connection: close, the curl client will "hang" for the duration of the timeout
proxy.config.http.keep_alive_no_activity_timeout_in
I'll examine the code some, maybe it would make sense to try to force close the UA connection prematurely here, but I suspect that might violate the RFCs? I'll have to check with the docs and some authorities.
All in all, I think we generally do the right things here, and it ought to be fairly safe to remove this check. It might make sense to make it a configurable option to re-enable the check, just in case, at least until some later version.
> Less draconian checks on Content-Length: + Connection: close from origin
> ------------------------------------------------------------------------
>
> Key: TS-500
> URL: https://issues.apache.org/jira/browse/TS-500
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Reporter: Leif Hedstrom
> Assignee: Leif Hedstrom
> Fix For: 2.1.4
>
>
> I think we should relax our checks on when to not trust the content-length header from Origin. We have a particularly troublesome case, which breaks youtube and possibly other streaming media sites:
> ////////////////////////////////////////////////////////
> // this is the case that the origin server sent //
> // us content length. Experience says that many //
> // origin servers that do not support keep-alive //
> // lie about the content length. to avoid truncation //
> // of docuemnts from such server, if the server is //
> // not keep-alive, we set to read until the server //
> // closes the connection. We sent the maybe bogus //
> // content length to the browser, and we will correct //
> // the cache if it turnrd out that the servers lied. //
> ////////////////////////////////////////////////////////
> if (incoming_response->presence(MIME_PRESENCE_CONTENT_LENGTH)) {
> if (s->current.server->keep_alive == HTTP_NO_KEEPALIVE) {
> s->hdr_info.trust_response_cl = false;
> s->hdr_info.response_content_length = HTTP_UNDEFINED_CL
> I'd like to suggest that we make this case optional (enabled / disabled via a records.config option). This would obviously require extensive testing, and probably should be enabled by default (i.e. preserver current behaviour).
> From the BIS RFC:
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-12#section-3.3
> If the actual number of
> octets sent in the message is more than the indicated Content-
> Length, the recipient MUST only process the message-body up to
> the field value's number of octets; the remainder of the message
> MUST either be discarded or treated as the next message in a
> pipeline.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TS-500) Less draconian checks on Content-Length:
+ Connection: close from origin
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom resolved TS-500.
------------------------------
Resolution: Fixed
> Less draconian checks on Content-Length: + Connection: close from origin
> ------------------------------------------------------------------------
>
> Key: TS-500
> URL: https://issues.apache.org/jira/browse/TS-500
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Reporter: Leif Hedstrom
> Assignee: Leif Hedstrom
> Fix For: 2.1.4
>
> Attachments: TS-500.diff
>
>
> I think we should relax our checks on when to not trust the content-length header from Origin. We have a particularly troublesome case, which breaks youtube and possibly other streaming media sites:
> ////////////////////////////////////////////////////////
> // this is the case that the origin server sent //
> // us content length. Experience says that many //
> // origin servers that do not support keep-alive //
> // lie about the content length. to avoid truncation //
> // of docuemnts from such server, if the server is //
> // not keep-alive, we set to read until the server //
> // closes the connection. We sent the maybe bogus //
> // content length to the browser, and we will correct //
> // the cache if it turnrd out that the servers lied. //
> ////////////////////////////////////////////////////////
> if (incoming_response->presence(MIME_PRESENCE_CONTENT_LENGTH)) {
> if (s->current.server->keep_alive == HTTP_NO_KEEPALIVE) {
> s->hdr_info.trust_response_cl = false;
> s->hdr_info.response_content_length = HTTP_UNDEFINED_CL
> I'd like to suggest that we make this case optional (enabled / disabled via a records.config option). This would obviously require extensive testing, and probably should be enabled by default (i.e. preserver current behaviour).
> From the BIS RFC:
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-12#section-3.3
> If the actual number of
> octets sent in the message is more than the indicated Content-
> Length, the recipient MUST only process the message-body up to
> the field value's number of octets; the remainder of the message
> MUST either be discarded or treated as the next message in a
> pipeline.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.