Description
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
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
- server response
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>
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.