reccmo wrote:Max has helped me substantially with providing php code for handling the new generic IMSLP redirect on the WIMA server.
The main challenge was to prevent infinite Apache loops for WIMA URLS bounced back to the WIMA server. I believe it's working now and have replaced the WIMA redirects based on IMSLP's upload log by the new generic IMSLP redirect. On the WIMA server a simple .htaccess file in the score root folder and a php redirect handler in the document root folder are involved.
I encourage forum readers to test the redirects of WIMA files, transferred as well as not transferred. Please report any errors encountered.
Unfortunately it turns out that this redirect method conflicts with IMSLP's WIMA upload logic. When you access a thus redirected WIMA file then the WIMA upload ends up with an error message like
File #1 Error: Error: Failure #47 on CURL for 'http://icking-music-archive.org/scores/amann/Amann-SymphoniePastorale.pdf'
I've been discussing this problem with Max, who says
Error 47 for CURL is "too many redirects":
CURLE_TOO_MANY_REDIRECTS (47)
Too many redirects. When following redirects, libcurl hit the maximum amount. Set your limit with CURLOPT_MAXREDIRS.
I'm not sure that the problem is due to the downloading being managed by php "per se", as it is essentially transparent to the browser. I think that there might be two possible causes:
1) a recursion issue similar to the one that we solved yesterday, but seen from the IMSLP side rather than from the WIMA side;
2) the php downloading being fragmented into small chunks of 2048 bytes. If CURL accounts a redirection for each chunk, it is easy to hit the CURL limit.
Cause 1) should be possibly fixed by Feldmahler, so let's investigate case 2) first. I would suggest to change this instruction on Redirect.php:
$buffer = fread($fd, 2048);
using a much larger value than 2048, so that the file is not fragmented, or fragment in very few chunks. To the limit, one can use:
$buffer = fread($fd, $fsize);
That should always result in a single file chunk.
If the above modification solves the issue, we may conclude that cause 2) applies. If it doesn't, I guess we will have to investigate cause 1) with Feldmahler.
The WIMA server side php logic includes ao. this logic
- Code: Select all
header("Content-type: ".$content_type);
header("Content-Disposition: inline; filename=\"".$path_parts["basename"]."\"");
header("Content-length: $fsize");
header("Cache-control: private");
while(!feof($fd)) {
$buffer = fread($fd, 2048);
echo $buffer;
}
fclose ($fd);
I've performed another upload with the fread buffer increased to the full file size ($fsize) - and still end up with error #47. So it looks like we need to look further into a recursion issue on the IMSLP server side.
Can the IMSLP generic redirect be set up to circumvent this problem? If not then a solution might be to let the generic redirect return the WIMA file path modified like
'http://icking-music-archive.org/scores/asola/Asola_O-Vos-Omnes-SAB.pdf' -> 'http://icking-music-archive.org/scores1/asola/Asola_O-Vos-Omnes-SAB.pdf'
On the WIMA server I've created a new directory, 'http://icking-music-archive.org/scores1/' including symlinks to all level 1 directories in 'http://icking-music-archive.org/scores/'.
For now I've taken back the 'old' redirect method into production.
