Ian Boston commented on SLING-6046:

The second request was a full GET that was aborted, probably by closing the 
connection, when the Accept: bytes header was sent. Although this might be a 
spec compliant behaviour is is a poor way of dealing with the issue. IE11 
should send the Range: header in the first instance. 
https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html section 14.5. states 
clients MAY send a Range header before the Accept: bytes header is send. Only 
when a Accept: none header is sent must they not send a Range header. Section 
14.35 of the specification allows for a Range: 0- header to be sent which 
allows the server to respond with the full body if it doesn't support Range 
headers, or the first n bytes if it does. This is the correct behaviour. The 
consensus is MS wont be fixing IE11 and if the same bug exists in in Edge they 
wont fix it there either as the spec can be interpreted either way. 

>From a Sling point of view the aborted request may cause problems, as, 
>depending on the Oak DataStore in use resources may have been allocated when 
>the request is aborted. If every large file request gets aborted first time 
>due to the Accept: bytes header being added, and those resources are allocated 
>through the http serving stream, then this patch as it stands may cause 
>problems for production deployments os Sling/AEM.

Section 14.35 of the spec appears to allow a Partial content (206) response 
with a Content-Range header to any response the server deems fit, rather than 
responding with Accept: range.


Sling should look at the content length of a resource. If that content length 
is > a configured size it should send a 206 partial content with a 
Content-Range header to all responses, even those with no Range header in the 
request. Where there is a Range header in the request, it should respond as 
that header instructs according to the specification.

wdyt ? Can you do a patch to cover that ?

This will avoid the first request being aborted, assuming IE11 is spec 
compliant to 206 responses that it did not explicitly request. You might have 
to experiment with the size of the first response as IE11 appears to be asking 
for 100K at a time which seems low.

> While Streaming Video to IE 11, StreamRendererServlet do not use Partial 
> Content Response [code 206]
> ----------------------------------------------------------------------------------------------------
>                 Key: SLING-6046
>                 URL: https://issues.apache.org/jira/browse/SLING-6046
>             Project: Sling
>          Issue Type: Bug
>          Components: Servlets
>    Affects Versions: Servlets Get 2.1.18
>            Reporter: Ashok Kumar
>         Attachments: Accept-Range Respone Header from S3.png, 
> NetworkDataS3VideoFromIE11.xml, S3video.html, StreamRendererServlet.java.patch
> Since IE 11 expects "Accept-Ranges" [0] response header to start making 
> requests with Range header, so sling lack in streaming of video content for 
> IE end users. We can add Accept-Ranges = bytes header to response , either 
> selectively only for video/mp4 mimetype ( video tag on IE looks for mp4 )  or 
> always.
> Without support of partial content response (206) for IE users, all large 
> video files are being downloaded in single chunk and user need to wait for 
> long to see video content playing. 
> [0] http://stackoverflow.com/questions/25654422/http-pseudo-streaming-in-ie11 

This message was sent by Atlassian JIRA

Reply via email to