A module of mine had a bug in it and, after sometime I decided to fix it. The problem was my code failed to handle redirects correctly. So I decided to switch to using drupal_http_request(). Useful little function indeed. But then, after deleting all my old cak code I was bemused, it still failed to handle redirects. Odd, what was going on, was the real bug somewhere else?
Well, no, as it turns out (after some print_r madness) it appears drupal_http_request() wasn't handling redirects either (for totally different reasons to my own cak handed code).
Here's what I found. Using this as a test URL http://www.alliance-leicester.co.uk which will redirect you to http://www.alliance-leicester.co.uk/home/index.asp?
Using wget -O > /dev/null this is what I get:-
Resolving www.alliance-leicester.co.uk... 188.8.131.52
Connecting to www.alliance-leicester.co.uk|184.108.40.206|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: /home/index.asp [following]
Reusing existing connection to www.alliance-leicester.co.uk:80.
HTTP request sent, awaiting response... 200 OK
Length: 28,976 (28K) [text/html]
Notice Location: /home/index.asp isn't a fully qualified URL, it's relying on on the parent/original URL for scheme and host. Now look at what drupal_http_request() does, it attempts to go straight there. But drupal_http_request() (recursively) requires a fully quallified URL.
The attached patch checks the URI in the Location for scheme and host. If they are missing it uses the original scheme/host details supplied.
After applying this patch/mod my module began working just fine and redirects are handled.
PASSED: [[SimpleTest]]: [MySQL] 40,711 pass(es). View
FAILED: [[SimpleTest]]: [MySQL] 40,750 pass(es), 2 fail(s), and 0 exception(s). View
FAILED: [[SimpleTest]]: [MySQL] 40,775 pass(es), 4 fail(s), and 0 exception(s). View
FAILED: [[SimpleTest]]: [MySQL] 40,584 pass(es), 24 fail(s), and 0 exception(s). View