Re: svn commit: r1163833 - /httpd/httpd/trunk/modules/http/byterange_filter.c
On Sep 1, 2011, at 2:44 PM, Roy T. Fielding wrote: On Sep 1, 2011, at 1:11 AM, Tim Bannister wrote: On Wed, Aug 31, 2011 at 6:28 PM, Roy T. Fielding wrote: On Aug 31, 2011, at 6:10 PM, William A. Rowe Jr. wrote: The presumption here is that the client requests bytes=0- to begin the transmission, and provided it sees a 206, restarting somewhere in the stream results in aborting the connection and streaming bytes=n- from the restart point. Further testing should determine if this was the broken assumption. Do we send the Accept-Ranges header field? http://tools.ietf.org/html/rfc2616#page-105 Apache httpd 2.2.9 is sending this header in the Debian bug report at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639825 Then the client is broken and they also break intermediary caches (most of which don't cache 206 responses) by performing this stunt. We could add a version-specific browsermatch to do the 206, but I'd prefer to just tell the client developers to fix their code. +1 from me.
RE: svn commit: r1163833 - /httpd/httpd/trunk/modules/http/byterange_filter.c
-Original Message- From: Jim Jagielski [mailto:j...@jagunet.com] Sent: Freitag, 2. September 2011 15:43 To: dev@httpd.apache.org Subject: Re: svn commit: r1163833 - /httpd/httpd/trunk/modules/http/byterange_filter.c On Sep 1, 2011, at 2:44 PM, Roy T. Fielding wrote: On Sep 1, 2011, at 1:11 AM, Tim Bannister wrote: On Wed, Aug 31, 2011 at 6:28 PM, Roy T. Fielding wrote: On Aug 31, 2011, at 6:10 PM, William A. Rowe Jr. wrote: The presumption here is that the client requests bytes=0- to begin the transmission, and provided it sees a 206, restarting somewhere in the stream results in aborting the connection and streaming bytes=n- from the restart point. Further testing should determine if this was the broken assumption. Do we send the Accept-Ranges header field? http://tools.ietf.org/html/rfc2616#page-105 Apache httpd 2.2.9 is sending this header in the Debian bug report at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639825 Then the client is broken and they also break intermediary caches (most of which don't cache 206 responses) by performing this stunt. We could add a version-specific browsermatch to do the 206, but I'd prefer to just tell the client developers to fix their code. +1 from me. I tend to +1 this as well. Regards Rüdiger
Re: svn commit: r1163833 - /httpd/httpd/trunk/modules/http/byterange_filter.c
On Wed, Aug 31, 2011 at 6:28 PM, Roy T. Fielding wrote: On Aug 31, 2011, at 6:10 PM, William A. Rowe Jr. wrote: The presumption here is that the client requests bytes=0- to begin the transmission, and provided it sees a 206, restarting somewhere in the stream results in aborting the connection and streaming bytes=n- from the restart point. Further testing should determine if this was the broken assumption. Do we send the Accept-Ranges header field? http://tools.ietf.org/html/rfc2616#page-105 Apache httpd 2.2.9 is sending this header in the Debian bug report at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639825 Tim
Re: svn commit: r1163833 - /httpd/httpd/trunk/modules/http/byterange_filter.c
On Sep 1, 2011, at 1:11 AM, Tim Bannister wrote: On Wed, Aug 31, 2011 at 6:28 PM, Roy T. Fielding wrote: On Aug 31, 2011, at 6:10 PM, William A. Rowe Jr. wrote: The presumption here is that the client requests bytes=0- to begin the transmission, and provided it sees a 206, restarting somewhere in the stream results in aborting the connection and streaming bytes=n- from the restart point. Further testing should determine if this was the broken assumption. Do we send the Accept-Ranges header field? http://tools.ietf.org/html/rfc2616#page-105 Apache httpd 2.2.9 is sending this header in the Debian bug report at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639825 Then the client is broken and they also break intermediary caches (most of which don't cache 206 responses) by performing this stunt. We could add a version-specific browsermatch to do the 206, but I'd prefer to just tell the client developers to fix their code. Roy
Re: svn commit: r1163833 - /httpd/httpd/trunk/modules/http/byterange_filter.c
On Aug 31, 2011, at 2:37 PM, s...@apache.org wrote: Author: sf Date: Wed Aug 31 21:37:38 2011 New Revision: 1163833 URL: http://svn.apache.org/viewvc?rev=1163833view=rev Log: Send a 206 response for a Range: bytes=0- request, even if 200 would be more efficient. 200 is a better response for caches as well. Why do we want to support this? Roy
Re: svn commit: r1163833 - /httpd/httpd/trunk/modules/http/byterange_filter.c
On Wednesday 31 August 2011, Roy T. Fielding wrote: Author: sf Date: Wed Aug 31 21:37:38 2011 New Revision: 1163833 URL: http://svn.apache.org/viewvc?rev=1163833view=rev Log: Send a 206 response for a Range: bytes=0- request, even if 200 would be more efficient. 200 is a better response for caches as well. Why do we want to support this? There seems to be at least one streaming client that gets confused by this behaviour. But maybe my commit was premature. If the change does not actually fix the problem, I will revert.
Re: svn commit: r1163833 - /httpd/httpd/trunk/modules/http/byterange_filter.c
On 8/31/2011 6:06 PM, Stefan Fritsch wrote: On Wednesday 31 August 2011, Roy T. Fielding wrote: Author: sf Date: Wed Aug 31 21:37:38 2011 New Revision: 1163833 URL: http://svn.apache.org/viewvc?rev=1163833view=rev Log: Send a 206 response for a Range: bytes=0- request, even if 200 would be more efficient. 200 is a better response for caches as well. Why do we want to support this? As explained to me by Stefan on irc... There seems to be at least one streaming client that gets confused by this behaviour. But maybe my commit was premature. If the change does not actually fix the problem, I will revert. The presumption here is that the client requests bytes=0- to begin the transmission, and provided it sees a 206, restarting somewhere in the stream results in aborting the connection and streaming bytes=n- from the restart point. Further testing should determine if this was the broken assumption.
Re: svn commit: r1163833 - /httpd/httpd/trunk/modules/http/byterange_filter.c
On Aug 31, 2011, at 6:10 PM, William A. Rowe Jr. wrote: On 8/31/2011 6:06 PM, Stefan Fritsch wrote: On Wednesday 31 August 2011, Roy T. Fielding wrote: Author: sf Date: Wed Aug 31 21:37:38 2011 New Revision: 1163833 URL: http://svn.apache.org/viewvc?rev=1163833view=rev Log: Send a 206 response for a Range: bytes=0- request, even if 200 would be more efficient. 200 is a better response for caches as well. Why do we want to support this? As explained to me by Stefan on irc... There seems to be at least one streaming client that gets confused by this behaviour. But maybe my commit was premature. If the change does not actually fix the problem, I will revert. The presumption here is that the client requests bytes=0- to begin the transmission, and provided it sees a 206, restarting somewhere in the stream results in aborting the connection and streaming bytes=n- from the restart point. Further testing should determine if this was the broken assumption. Do we send the Accept-Ranges header field? http://tools.ietf.org/html/rfc2616#page-105 Roy
