Incorrect read length, http and php

Matthew D. Fuller fullermd at over-yonder.net
Sat Oct 14 07:06:54 BST 2006


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?


As a workaround, I've added an
"AddType application/octet-stream .knit"
to the end of my Apache conf, which according to the doc below should
override (since ".knit" is the right-most "extension", and now it's
given an explicit Type).  And it seems to do the trick; the branch
runs merrily through to completion.  So that's something, anyway.



[0] <http://httpd.apache.org/docs/1.3/mod/mod_mime.html#multipleext>


-- 
Matthew Fuller     (MF4839)   |  fullermd at over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.




More information about the bazaar mailing list