[ https://issues.apache.org/jira/browse/TS-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811005#comment-13811005 ]
Leif Hedstrom commented on TS-1955: ----------------------------------- I have a patch for problem 2) above. That will at least make the requests function as they should, albeit "slow". With some more testing, I think we should focus this bug on that problem, and file an RFE for a new overridable configuration to solve problem 1). Thoughts? > read_while_writer sends wrong response for range request. > --------------------------------------------------------- > > Key: TS-1955 > URL: https://issues.apache.org/jira/browse/TS-1955 > Project: Traffic Server > Issue Type: Bug > Components: Core > Affects Versions: 3.2.4 > Reporter: jaekyung oh > Assignee: Leif Hedstrom > Labels: range > Fix For: 4.1.0 > > > Basically read_while_writer works fine when ATS handles normal file. > In progressive download and playback of mp4 in which moov atom is placed at > the end of the file, ATS makes and returns wrong response for range request > from unfulfilled cache when read_while_writer is 1. > In origin, apache has h264 streaming module. Everything is ok whether the > moov atom is placed at the beginning of the file or not in origin except a > range request happens with read_while_writer. > Mostly our customer’s contents placed moov atom at the end of the file and in > the case movie player stops playing when it seek somewhere in the movie. > to check if read_while_writer works fine, > 1. prepare a mp4 file whose moov atom is placed at the end of the file. > 2. curl --range xxxx-xxxx http://www.test.com/mp4/test.mp4 1> > no_cache_from_origin > 3. wget http://www.test.com/mp4/test.mp4 > 4. right after wget, execute “curl --range xxxx-xxxx > http://www.test.com/mp4/test.mp4 1> from_read_while_writer” on other terminal > (the point is sending range request while ATS is still downloading) > 5. after wget gets done, curl --range xxxx-xxxx > http://www.test.com/mp4/test.mp4 1> from_cache > 6. you can check compare those files by bindiff. > The response from origin(no_cache_from_origin) for the range request is > exactly same to from_cache resulted from #5's range request. but > from_read_while_writer from #4 is totally different from others. > i think a range request should be forwarded to origin server if it can’t find > the content with the offset in cache even if the read_while_writer is on, > instead ATS makes(from where?) and sends wrong response. (In squid.log it > indicates TCP_HIT) > That’s why a movie player stops when it seeks right after the movie starts. > Well. we turned off read_while_writer and movie play is ok but the problems > is read_while_writer is global options. we can’t set it differently for each > remap entry by conf_remap. > So the downloading of Big file(not mp4 file) gives overhead to origin server > because read_while_writer is off. -- This message was sent by Atlassian JIRA (v6.1#6144)