Bug: Crash on http-autodownload without content-length header

[RMF]

When setting up an autodownload speedlimit via PHP tonight, openarena (0.8.5) crashed when autodownloading. I could see it request the file and start downloading, but after a couple hundred packets it crashed: "VM_Free(ui) on running vm". The problem was that I had forgotten to make it set the content-length in the HTTP header.
I'm running Windows XP.

This is the crashlog (maybe it's usefull if someone ever has this crash and posts a similar console log or something.. you never know):

Code:

Need paks: @baseoa/speedyctf.pk3@baseoa/speedyctf.pk3
URL: http://example.com/[...]/baseoa/speedyctf.pk3
----- CL_Shutdown -----
----- FS_Startup -----
Current search path:
C:\Documents and Settings\Luc.LUC2\Application Data\OpenArena\RMFServer\zz-proskins2.pk3 (8 files)
C:\Documents and Settings\Luc.LUC2\Application Data\OpenArena/RMFServer
C:\Program Files\openarena\openarena-0.8.5/RMFServer
C:\Documents and Settings\Luc.LUC2\Application Data\OpenArena\baseoa\z_oasago2f9_god-final.pk3 (11 files)
C:\Documents and Settings\Luc.LUC2\Application Data\OpenArena\baseoa\z_am_thornish-b2.pk3 (27 files)
[...]
C:\Documents and Settings\Luc.LUC2\Application Data\OpenArena\baseoa\7+.pk3 (6 files)
C:\Documents and Settings\Luc.LUC2\Application Data\OpenArena\baseoa\6++.pk3 (9 files)
C:\Documents and Settings\Luc.LUC2\Application Data\OpenArena\baseoa\13base.pk3 (81 files)
C:\Documents and Settings\Luc.LUC2\Application Data\OpenArena/baseoa
C:\Program Files\openarena\openarena-0.8.5\baseoa\pak6-patch085.pk3 (559 files)
C:\Program Files\openarena\openarena-0.8.5\baseoa\pak6-misc.pk3 (229 files)
C:\Program Files\openarena\openarena-0.8.5\baseoa\pak5-TA.pk3 (139 files)
C:\Program Files\openarena\openarena-0.8.5\baseoa\pak4-textures.pk3 (1753 files)
C:\Program Files\openarena\openarena-0.8.5\baseoa\pak2-players.pk3 (669 files)
C:\Program Files\openarena\openarena-0.8.5\baseoa\pak2-players-mature.pk3 (231 files)
C:\Program Files\openarena\openarena-0.8.5\baseoa\pak1-maps.pk3 (100 files)
C:\Program Files\openarena\openarena-0.8.5\baseoa\pak0.pk3 (1042 files)
C:\Program Files\openarena\openarena-0.8.5/baseoa

handle 1: video/idlogo.roq
----------------------
14746 files in pk3 files
Closing SDL audio device...
SDL audio device shut down.
RE_Shutdown( 1 )
----- CL_Shutdown -----
WARNING: Recursive shutdown
----- CL_Shutdown -----
WARNING: Recursive shutdown

When looking in Wireshark (packet sniffer), you can see it download about 180KB before it sends a TCP connection reset packet to stop the download (this is when openarena crashes). Maybe it defaulted to some length to allocate in the memory when it didn't receive the filesize, used the memory already allocated by OA until it was full, or crashed when it tried to create the tempfile to write the data to?

I mentioned this requirement for autodownload to work on the openarena wiki:
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Manual/Automatic_downloading#In_short


Btw another thing about http-downloads, I wonder what this is for:

GET /[...]/baseoa/speedyctf.pk3 HTTP/1.1
User-Agent: menu/art/sliderbutt_1.tga
Host: example.com
Accept: */*
Referer: menu/art/sliderbutt_0.tga

Looking in the svn on this site, I don't see why the sliderbutt images are referenced to...


Edit: Oh and this bugreport is more a 'just so you know'-one than something which needs to get fixed badly. It's always better if the server sends a content-length header, but if it doesn't the client shouldn't crash but at most give an error or something.

[Gig]

Sorry for resuming an old thread.... anyway, the question is: can you try if with version28 executables the problem still occurs? If not anymore, okay... if yes, I suppose we should try if the same happens with ioquake3, and if that is the case, we should open a bug report there...

[grey matter]

Btw another thing about http-downloads, I wonder what this is for:

GET /[...]/baseoa/speedyctf.pk3 HTTP/1.1
User-Agent: menu/art/sliderbutt_1.tga
Host: example.com
Accept: */*
Referer: menu/art/sliderbutt_0.tga

IIrc the user agent should match the "version" cvar plus cURL version, not some seemingly random local filename. Referer should be "ioQ3://" plus server IP:port.
Please test whether this is still true as well, as it's definitely a bug On a sidenote; you'll get some cURL debug output from OA (among other additional debug output) by "/set developer 1".

P.S.: It'd be great if you could post a stripped down PHP script to try reproducing the bug. You can certainly achieve this via other methods, but we're all too lazy to do this ourself.

[RMF]

I don't have much time last days (some may notice I didn't play at all last week), but I've setup a simple autodl script at http://easyupload.nl/ (set that as sv_dlURL). When trying to load /baseoa/[pk3] it should serve you the file which gets loaded by PHP from /maps (you can view that one: http://easyupload.nl/maps). For now there is only one map in, one I thought many wouldn't already have, and it's just for a test after all.
For some reason it doesn't send a content-length header though, or so Tamper Data in Firefox shows. When trying another header (which is still in the source) you see it appear. When trying "die(filesize($file).'');" it shows the correct filesize in bytes. I'll debug later. For now, here is the PHP script:

Code:

<?php 
// $_GET["f"] is "/baseoa/[filename].pk3"
if (false !== strpos($_GET["f"], "/baseoa/")) {
$map = substr($_GET["f"], strpos($_GET["f"], "/baseoa/") + strlen("/baseoa/"));
$file = "maps/" . $map;
//I assume the map exists.
header("test: one");
header("Content-length: " . filesize($file));
echo file_get_contents($file); //not memory efficient, but it is short ^^
exit;
}

Once I test it and get it working, I'll also test without content-length header and let you know the results.

P.S. Don't ask about the domain, long story .

[grey matter]

Without having tested this in OA; it's "Content-Length", with an uppercase L. Besides your script is sending the pk3 as "text/html" instead of "application/zip".

[RMF]

Content-type is unimportant I think, I didn't have it in the original script. And I thought headers were case insensitive, but maybe not then.

Thanks for reminding me by replying, otherwise I'd have totally forgotten to do this x)

[GrosBedo]

Content-type is unimportant I think, I didn't have it in the original script. And I thought headers were case insensitive, but maybe not then.

It is VERY important, else the browser can't know how to deal with the file. Maybe your original script worked because the server was configured to deal with these files using an .htaccess or in the php.ini or apache conf file, but you shouldn't rely on those things to deal with the files.

And it IS case-sensitive, and even SPACE sensitive. So be very careful with headers.

[RMF]

I meant it probably doesn't matter to OA. I don't really care about browsers for an autodownload script.

[GrosBedo]

I meant it probably doesn't matter to OA. I don't really care about browsers for an autodownload script.

If I'm not mistaken, the headers are processed through apache which will then do some other stuffs, so that it should have some implications for OA as well.

[RMF]

"Some other stuffs", care to explain?

[GrosBedo]

Apache can force the content type itself (so be careful with apache config too), and it tries to optimize the content negotiations with the client:

http://httpd.apache.org/docs/2.0/en/content-negotiation.html