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 2014/12/16 18:59:15 UTC

[jira] [Updated] (TS-3054) Premature origin connection reset: flush partial data received to client before closing client connection

     [ https://issues.apache.org/jira/browse/TS-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Leif Hedstrom updated TS-3054:
------------------------------
    Summary: Premature origin connection reset: flush partial data received to client before closing client connection  (was: premature origin connection reset: flush partial data received to client before closing client connection)

> 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: 5.2.0
>
>         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)