Bug 33897 - Downloading protected content cannot be resumed.
Summary: Downloading protected content cannot be resumed.
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_access (show other bugs)
Version: 2.0.40
Hardware: PC Linux
: P2 critical (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: RFC
Depends on:
Blocks:
 
Reported: 2005-03-08 11:09 UTC by Tamas Solymosi
Modified: 2005-06-03 08:21 UTC (History)
0 users


Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tamas Solymosi 2005-03-08 11:09:49 UTC 
- Try to download any content that is protected with e.g. Basic authentication.
- Cancel transaction after some bytes received
- Resume the download from the very last byte the client received. Use 'Range' 
in request header.

Apache server's response:
206 Partial Content and some dummy message in the body.

The problem is that a client application can only see that something went wrong 
if it uses some heuristic: response header contains 'WWW-Authenticate' field 
and the content-length is different from the original content length.

Server's response should be 401 instead of 206.
Comment 1 Paul Querna 2005-06-03 00:02:23 UTC 
in byterange_filter.c, we are blindly setting
r->status = HTTP_PARTIAL_CONTENT;
if it meets the other conditions of a byte range request.  In the simple case,
this means when returning a 401, we will send them a range of the 401 error, not
the actual part of the file they wanted.

I think we should decline to do byte range requests if status is
!ap_is_HTTP_SUCCESS(r->status).

Thoughts?

This would imply that you can never do a byte range request of any error pages...
Comment 2 Joe Orton 2005-06-03 16:21:33 UTC 
This was fixed a long time ago, it's handled by ap_set_byterange().