Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Redirect delegate call sequence fix #301

wants to merge 1 commit into from

2 participants


Currently, the requestRedirected delegate method will be called right after the header is parsed. However, the data received delegate method which comes together with the redirected header will be called after the requestRedirected callback.

The sequence is like this:

  1. HTTP Redirect Header
  2. requestRedirected
  3. HTTP Redirect Body (usually some simple html indicate the redirection)
  4. dataReceived
  5. HTTP Header
  6. headerReceived
  7. HTTP Body
  8. dataReceived

I think in this sequence, step 4 may cause bugs. The delegate is most likely accumulating the received data for writing to file, live parsing, etc. Apparently, we should not append the data received from step 4 to step 8. The most straight forward thought is to "reset" the data status after the request being redirected but that actually happens before step 4.

I propose to move the step 2 between step 4 and 5.

@yllan yllan referenced this pull request

Redirect fix #300


There is actually a check in handleBytesReceived that returns before calling the dataReceived delegate if there is a redirect happening. This redirect flag is set at step 1 during response header reading and reset after step 4. Hence, it should be fine in this case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jan 16, 2012
  1. @yllan

    Call requestRedirected after the request is actually redirected, not …

    yllan authored yllan committed
This page is out of date. Refresh to see the latest.
Showing with 1 addition and 2 deletions.
  1. +1 −2  Classes/ASIHTTPRequest.m
3  Classes/ASIHTTPRequest.m
@@ -1466,6 +1466,7 @@ - (void)performRedirect
} else {
// Go all the way back to the beginning and build the request again, so that we can apply any new cookies
[self main];
+ [self performSelectorOnMainThread:@selector(requestRedirected) withObject:nil waitUntilDone:[NSThread isMainThread]];
@@ -2314,8 +2315,6 @@ - (BOOL)willRedirect
return NO;
- [self performSelectorOnMainThread:@selector(requestRedirected) withObject:nil waitUntilDone:[NSThread isMainThread]];
// By default, we redirect 301 and 302 response codes as GET requests
// According to RFC 2616 this is wrong, but this is what most browsers do, so it's probably what you're expecting to happen
// See also:
Something went wrong with that request. Please try again.