eliseuamaro/gnu-social
1
0
Fork 0
forked from GNUsocial/gnu-social
Code Issues Pull Requests Releases Wiki Activity

Workaround for yfrog.com photo attachments: fudge File_redirection::lookupWhere()'s HTTP handling -- when we get a 204 on a HEAD, double-check it by re-running as a GET. yfrog.com returns a 204 incorrectly for this case.

Browse Source
This commit is contained in:
Brion Vibber 2010-11-15 11:01:00 -08:00
parent e1ffbfed04
commit 1c90d09ec8
1 changed files with 20 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
classes/File_redirection.php
View File

@ -91,9 +91,16 @@ class File_redirection extends Memcached_DataObject
$request->setMethod(HTTP_Request2::METHOD_HEAD);
$response = $request->send();
if (405 == $response->getStatus()) {
if (405 == $response->getStatus() || 204 == $response->getStatus()) {
// HTTP 405 Unsupported Method
// Server doesn't support HEAD method? Can this really happen?
// We'll try again as a GET and ignore the response data.
//
// HTTP 204 No Content
// YFrog sends 204 responses back for our HEAD checks, which
// seems like it may be a logic error in their servers. If
// we get a 204 back, re-run it as a GET... if there's really
// no content it'll be cheap. :)
$request = self::_commonHttp($short_url, $redirs);
$response = $request->send();
}
@ -235,6 +242,18 @@ class File_redirection extends Memcached_DataObject
return null;
}
/**
* Basic attempt to canonicalize a URL, cleaning up some standard variants
* such as funny syntax or a missing path. Used internally when cleaning
* up URLs for storage and following redirect chains.
*
* Note that despite being on File_redirect, this function DOES NOT perform
* any dereferencing of redirects.
*
* @param string $in_url input URL
* @param string $default_scheme if given a bare link; defaults to 'http://'
* @return string
*/
function _canonUrl($in_url, $default_scheme = 'http://') {
if (empty($in_url)) return false;
$out_url = $in_url;