[
https://issues.apache.org/jira/browse/TS-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-3054:
-------------------------------
Attachment: ts-3054.patch
The State Machine was both aborting the cache write and halting returning data
to the client in the case of a malformed chunked response.
The data certainly should not be cached. But if the server is sending a
non-standard response (as is the case here), it seems that ATS is being less
transparent by dropping the response.
Nikolai, could you give this patch a try? It fixes the problem against the
site you referenced in my simple environment. I tested it against master, but
it patches against 5.0.1 too.
> premature origin connection reset: flush partial data received to client
> before closing client connection
> ---------------------------------------------------------------------------------------------------------
>
> Key: TS-3054
> URL: https://issues.apache.org/jira/browse/TS-3054
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core, HTTP
> Affects Versions: 5.0.0, 5.0.1
> Reporter: Nikolai Gorchilov
> Assignee: Susan Hinrichs
> Fix For: sometime
>
> Attachments: ts-3054.patch
>
>
> Having a case with misbehaving online service in forwarding proxy mode: the
> origin server responds with chunked encoding, but closes the connection
> before sending the final 0\r\n\r\n chunk. I know it’s against the standards,
> but all browsers seem to be fine using the "partial" data received.
> It would be great to have the following logic implemented in ATS: in case of
> premature connection reset, forward and flush all available data before
> closing the second connection. Currently ATS seems to reset the connection
> without forwarding the partially available data.
> Here’s a real-life example:
> http://www.indiancivils.com/virtual/ShowVideoTrial.aspx?VidId=86
> Once the flash object on the above webpage is loaded it makes authorization
> request to
> http://www.authorlive.com/aliveext/ValidRecordingToken.aspx?t=13071753&r=2688:
> * client request
> {noformat}
> GET /aliveext/ValidRecordingToken.aspx?t=13071753&r=2688 HTTP/1.1
> Host: www.authorlive.com
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0)
> Gecko/20100101 Firefox/31.0
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-US,en;q=0.5
> Accept-Encoding: gzip, deflate
> Referer:
> http://ocnstream.s3.amazonaws.com/VCBLoader.swf?r=R4404876_V4&e=&l=1&c=1&t=13071753
> Connection: keep-alive
> {noformat}
> * server response
> {noformat}
> HTTP/1.1 200 OK
> Date: Sun, 31 Aug 2014 10:00:38 GMT
> Server: Microsoft-IIS/6.0
> X-Powered-By: ASP.NET
> X-AspNet-Version: 4.0.30319
> Transfer-Encoding: chunked
> Cache-Control: no-cache
> Pragma: no-cache
> Expires: -1
> Content-Type: application/xml;; charset=utf-8
> 34
> <recording><validtoken>true</validtoken></recording>
> {noformat}
> Here the origin server resets the connection without sending the closing
> chunk.
> ATS closes the client’s connection without forwarding the existing
> "34\r\n<recording><validtoken>true</validtoken></recording>" chunk.
> As a result the flash application complains with "You are not authorized to
> watch this recording !”, effectively prohibiting the user from watching the
> pre-recorded online class session.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
