Just to confirm, you're seeing this behavior with both 302s and 307s?

Yes, with 302 and with 307

Aaron can you take a look?

Do you have a sample URL I can test with?

My setup is a little complication, but here's a simple repro:

From your server, issue a 302 with location "http://freshly-ground.com/data/audio/sm2/20060924%20-%20Ghosts%20&%20Goblins%20Reconstructed.ogg" like so (PHP):

        header( "HTTP/1.0 302 Found" );
        header( "Location: http://freshly-ground.com/data/audio/sm2/20060924%20-%20Ghosts%20&%20Goblins%20Reconstructed.ogg" );
        return;

Put in your server URL and watch the network tab in Chrome's Debugger. 
You'll see the original request to your server respond with the 302, and then two requests to freshly-ground.com. 

What you *should* see is the 302 followed by a request to freshly-ground.com and then another request to your server, resulting in a new 302 followed by another request to freshly-ground.com.

Segue -- Ideally, Chrome wouldn't need to make two requests for this. Firefox doesn't. But I think that's  Issue 56467 .

I can't seem to reproduce the problem. I'm only seeing 1 request. I've attached the files that I am trying to repro this issue with.

redirect-test.html 128 bytes View Download

redirect.php 176 bytes View Download

I think the problem is that you're using the <audio> tag. Enter the URL directly in the browser URL bar.

Anyway, I put up a URL for you to easily repro this:
http://www.audiogalaxy.com/chromeOggBug.ogg

Here's how the result looks in a Chrome Incognito Window in the debugger:

	Bad302Handling.png 161 KB View Download

Ah ha. That is the problem. I can repro this now. Thanks.

any plan to fix for m12?

I can reproduce this behavior, but I'm not sure the behavior the reporter expects is valid. 

I've put the URL that redirects into the address bar on both Chrome & Firefox and the behavior is the same. The redirect changes the address in the address bar and the browser makes 2 requests to the new address before starting playback. 

If you actually put the URL in a <audio> then it has the behavior the reporter expects.

I've tried standard web pages with similar redirects and they change the address bar as well. I don't think we want to make media URLs special in this regard.

Comment #11 doesn't seem accurate. Firefox is definitely not causing a brand-new http request to happen to the destination URL, while Chrome is.

This issue actually affects the Audiogalaxy application (www.audiogalaxy.com). What I provided above was a simplified repro. Audiogalaxy produces one-time URLs for audio resources (ogg, in this case). A browser request for resource A cause a one-time URL A' to be issued. Firefox makes only one request for A and proceeds to play the audio from the redirected location A'. Chrome on the other hand makes a request for A, proceeds to make a request to A' and then makes another request to A' instead of A. The fact that A' was a one-time-use resource means the second request fails. I read the HTTP spec again and it certainly says that the result of a redirect should be used only once. So if Chrome made that second request to A, all would be well.

This can be very easily reproduced with Audiogalaxy - I can provide login credentials and repro information if it'll help. You can email me on help at audiogalaxy.com (mention this bug in the subject) and I'll reply with details.

I will do some more investigation tomorrow and see what I come up with. I'll likely take you up on your offer for credentials so I can see the exact situation you are seeing. My guess is that there may be a code path that I'm overlooking.

Quick status update:
I'm able to reproduce the behavior with the credentials sent to me. It appears the problem is caused by the browser getting an unexpected HTTP/1.0 response to an HTTP/1.1 Range request. This situation doesn't happen in the previous repro examples which is why I wasn't seeing the behavior the reporter mentioned. While the HTTP/1.0 response is valid according to the HTTP spec, the current code doesn't handle it correctly when it happens on a redirect target. The code detects the unexpected range response and reissues a modified version of the request w/o taking into consideration that the error happened on a redirected URL.

I'm continuing to investigate this.

Punting to M13

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=82061

------------------------------------------------------------------------
r82061 | acolwell@chromium.org | Mon Apr 18 20:12:32 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/media/buffered_data_source.cc?r1=82061&r2=82060&pathrev=82061
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/media/buffered_data_source_unittest.cc?r1=82061&r2=82060&pathrev=82061
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/media/buffered_resource_loader_unittest.cc?r1=82061&r2=82060&pathrev=82061
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/media/buffered_resource_loader.h?r1=82061&r2=82060&pathrev=82061
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/media/buffered_resource_loader.cc?r1=82061&r2=82060&pathrev=82061

Fix BufferedResourceLoader so it only makes Range requests when a subset of the file is needed.

BUG= 74975 
TEST=none

Review URL: http://codereview.chromium.org/6815012
------------------------------------------------------------------------

Fix checked in and will be included as part of M12 release

Reopening. Had to revert fix for M12 because it caused regressions in a variety of other sites. Will start working on an new fix for M13 immediately.

any updates or are we thinking m14?

Still blocked on  issue 81820 . I believe I've worked things out with rvargas@ so the cache code will get fixed.

I believe this was fixed by rvargas@ 

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.