Dear developers,
I'm stuck with this problem for a couple of hours and would like to report it to you.
When trying to retrieve resource from MySpace with HEAD method, for instance https://myspace.com/lorem_ispum, the result is "47 - Maximum (3) redirects followed".
The only way I found to make it work is to:
- switch method to GET and modify
_chr_curl_set_port by replacing $uri['port'] != 80 with $uri['port'] != 80 && $uri['port'] != 443
But I'm convinced it's not the best solution as it modifies the body of the module and by default the module works quite good for other sites.
Would you have an idea how to get resources on MySpace with HEAD method ?
Thanks a lot,
Best regards,
Alexandre 8)
Comments
Comment #1
alexboss commentedSimilar problem encountered with Flickr this time.
When trying to retrieve resource from Flickr with HEAD method, for instance https://myspace.com/lorem_ispum, the result is "HTTP/1.1 404 Not Found on Accelerator".
The only way I found to make it work is to modify _chr_curl_set_port by replacing $uri['port'] != 80 with $uri['port'] != 80 && $uri['port'] != 443
Best regards,
Alexandre
Comment #2
alexboss commentedOK here is a patch for this issue (7.x-1.6 and 7.x-1.7).
To summarize:
* If port different from standard and default one Then add port number to Header Host
* Otherwise discard adding port number to Header Host
Best regards,
Alexandre
Comment #3
kupide commentedNice ;) !
Works for me , please commit.
Comment #4
alexboss commentedHello guys,
Apparently there was a problem with the previous patches preventing them to be applied.
Please find the updated and corrected versions.
Sorry for the inconvenience,
Alexandre 8)
Comment #5
alexboss commentedComment #6
s.perilhou commentedHello,
Got false 404 on HTTPS requests these days. It may come from a recent php5-curl update on my servers.
After this patch, all came back to normal.
Please add it to next release ! :)
Comment #7
retorque commentedThis problem can also occur when using chr to override drupal_http_request() for the linkchecker module, checking internal links behind an https-terminating load balancer and Varnish reverse proxy. For me, the requests were getting as far as Varnish, but with port 443 tacked onto the host, and not getting through to Apache from there.
Patch in comment 4 for 1.7 worked for me, manually applied to 1.9.
Comment #8
spaghettibolognese commented#4 looks correct and fixes the error for me.