Incorrect read length, http and php

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew D. Fuller wrote:
> On Thu, Sep 21, 2006 at 12:23:26PM -0400 I heard the voice of
> Aaron Bentley, and lo! it spake thus:
>> David Allouche wrote:
>>> This problem has probably not been reported before because I do
>>> not think there are many php-based projects using bzr. But it's
>>> still here lurking to bite unsuspecting dumb-server clients.
>> It's not just that the server has php enabled, it's that the server
>> has a terrible rule for detecting php files.  My organization has
>> php enabled on our server, and I've never had that kind of problem
>> serving knits.
> 
> (Dredging up old threads)
> 
> I've just had this bite me, and it may just qualify as the weirdest
> damn thing I've seen in a month.  I can see why it's happening, but I
> can't see WHY it's happening, if you follow me (I don't).  This
> happens with both pycurl and urllib for me; I'm not sure how it could
> have made a difference anyway, since the client doesn't get much say
> in how the server interprets a file internally...
> 
> This server has an "AddType application/x-httpd-php .phtml" directive
> in place for hysterical raisins.  When I try to branch over HTTP from
> the server, it croaks trying to grab the knit
> "pdf.phtml.bak.php-20060719235204-41b15f0c5ad6c6f0.knit" when the
> server tries to interpret it as PHP.  Presumably, this happens because
> the ".phtml" gets interpreted as an extension, even though it's not at
> the end (the '.php' wouldn't be so interpreted, since it's got a dash
> and not a period after it, which explains why this doesn't come up
> commonly; the 'extension' has to be not at the end of the filename for
> it to be left isolated between periods when bzr makes a file-id from
> it)[0].  So far, so "good".
> 
> But, wait a minute.  Just .167 seconds prior to that I requested
> "verify.phtml.bak.php-20060719235204-30107abafd0a2b77.knit" and it
> returned it just fine.  For that matter, another few hundredths of a
> second back, we got
> "pdf.phtml.bak.php-20060719235204-88d494e0656568e8.knit" (same
> filename from different directory in the source tree), which is
> _identical_ except for the pseudo-random stuff between the timestamp
> and ".knit", and IT didn't get interpreted either!  What the hell?!
> 
> So, now I'm all confuzzled; I can sorta see why Apache, in its
> Infinite Wisdom, decided to try jamming the file through the PHP
> interpreter.  But, why didn't it try to jam the REST through?

To be honest, I'd never imagined this was part of the built-in Apache
behavior.  I thought this was the result of a bogus 'addType' declaration.

I can kind of see how this might make sense if you're serving multiple
languages statically, and designing Apache to serve documents, not
files.  But personally, I'd write it so that it stopped at the first
unrecognized extension.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFMQDG0F+nu1YWqI0RAoAIAJ9gPIKR2wZFl97ibLVeeY0wAXMxfQCffKm4
aRbdOlPatA/ZRPM0aU8PR1w=
=dVMe
-----END PGP SIGNATURE-----