Server change affecting ability to send downloaded files???

Server change affecting ability to send downloaded files???

am 08.08.2009 01:28:57 von Brian Dunning

Hey all --

A couple of weeks ago my online stores, on a machine I host at
Rackspace, stopped delivering files that people purchase. I've used
this for years, and it's always worked perfectly with all filetypes:

header('Content-Type: application/octet-stream');
header('Content-Disposition: attachment; filename="'.
$file_row["filename"].'"');
$size = filesize('../../store/files/'.$file_row['filename']);
header('Content-Length: '.$size);
readfile('../../store/files/'.$file_row['filename']);

But then, all of a sudden, it only works with ZIP files. There were no
changes to the code or to the files, just one day all of a sudden any
time someone purchases a DMG, EXE, PDF, etc. they get zero bytes. I've
asked Rackspace if they upgraded something that might produce this
change but they say "check your code". The code had not been touched
in years (literally). I've tried a zillion combos of different headers
but I'm having no luck.

Has anyone ever heard of something (besides my code and my files) that
could cause this behavior? You'll be my best friend if you can help.
Thanks.



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Server change affecting ability to send downloaded files???

am 08.08.2009 01:54:22 von Ben Dunlap

> changes to the code or to the files, just one day all of a sudden any
> time someone purchases a DMG, EXE, PDF, etc. they get zero bytes. I've
[8<]
> Has anyone ever heard of something (besides my code and my files) that
> could cause this behavior? You'll be my best friend if you can help.
> Thanks.

That list of failing file types makes me suspect some sort of anti-malware
software at the perimeter of Rackspace's network. Could also be anti-malware on
the users' machines, but if this is happening to a wide cross-section of users,
I'd doubt the latter.

Plus, in the latter case, I would expect the users' machines to end up with no
file on disk at all, but it sounds like they're getting empty files instead.

You'd think Rackspace would know about potentially destructive changes to their
perimeter, but my experience with their first-level support is that they are
wonderfully friendly and well-intentioned but could sometimes be
better-informed.* Have you been able to push through to second-level support or
beyond?

You might have to tweak your code a bit to support your case to Rackspace (and
make double-darn-sure it's actually not your problem): for example, you could
grab the return value of readfile() and write it to a log file (or just call
error_log() to write it to the PHP error log).

This will prove that your code is actually sending bytes across the wire. Even
if your headers are wrong -- which they obviously aren't, if the code works for
some file types -- your users shouldn't be getting 0 bytes if readfile() is
reporting otherwise.

Ben

*I don't intend to bash on Rackspace here -- I'm a very happy customer of
theirs for email and Cloud Servers. I always give them an 8 or a 9 on
customer-satisfaction surveys, and then explain my frustration with their
first-level support in the "comments" section.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Server change affecting ability to send downloaded files???

am 08.08.2009 02:04:13 von Brian Dunning

Very interesting. Excellent debugging advice. It's giving me a 500
error, probably why the Rackspace techs told me to check my code:

HTTP/1.0 500 Internal Server Error
Date: Sat, 08 Aug 2009 00:01:10 GMT
Server: Apache/2.0.52 (Red Hat)
X-Powered-By: PHP/5.2.10
Content-Disposition: attachment; filename="Installer.bin"
Content-Length: 23223296
Connection: close
Content-Type: application/octet-stream

I'm at a loss. Nothing changed in the code and it works for ZIP files.


On Aug 7, 2009, at 4:57 PM, Adam Randall wrote:

> Can you do a commandline test with curl to see what you get back?
>
> curl -I http://url/file.php?something=here
>
> That should allow you to see what is actually being produced by the
> code, and if it's being tweaked in some manner unknown to you.
>



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Server change affecting ability to send downloaded files???

am 08.08.2009 02:05:06 von Brian Dunning

Correct, the files on the server have not changed either, and have
been working fine for a long time. No funny characters.

On Aug 7, 2009, at 4:59 PM, Adam Randall wrote:

> Sorry for replying to myself, but the files themselves only contain
> US-ASCII characters, and no quotes, correct? Having extended
> characters in your file names might cause weirdness, and quotes will
> break your HTTP header in your code there.
>



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Server change affecting ability to send downloaded files???

am 08.08.2009 02:16:38 von Ben Dunlap

> Very interesting. Excellent debugging advice. It's giving me a 500
> error, probably why the Rackspace techs told me to check my code:
>
> HTTP/1.0 500 Internal Server Error

Did you get that 500 while running curl from a machine outside of Rackspace's
network?

If so, I'd be interested to see what you get if you run it from the server's
command line (using 'localhost' in the URL you pass to curl).

Have you checked your Apache error log as well, and PHP's? There will usually
be more detail in those locations when the server sends a 500.

Ben

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Server change affecting ability to send downloaded files???

am 08.08.2009 02:19:21 von Adam Randall

Change to cron -i to see what other information, if any, is also being
passed back. You might get some errors, or some such. Since you are
getting empty files my gut tells me you aren't getting anything. Since
you are actually getting a PHP 500 error, that lends me to believe
that it's not some type of external influence (aka the malware
thoughts).

Since the code looks reasonable, I'm thinking that it may be
permission related. While your code/files may not have been updated,
that doesn't mean that permissions were not. Trace through your file
structure and see what's going on in the ../../store/files path.

Adam.

On Fri, Aug 7, 2009 at 5:05 PM, Brian Dunning wrote:
> Correct, the files on the server have not changed either, and have been
> working fine for a long time. No funny characters.
>
> On Aug 7, 2009, at 4:59 PM, Adam Randall wrote:
>
>> Sorry for replying to myself, but the files themselves only contain
>> US-ASCII characters, and no quotes, correct? Having extended
>> characters in your file names might cause weirdness, and quotes will
>> break your HTTP header in your code there.
>>
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



--
Adam Randall
http://www.xaren.net
AIM: blitz574

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Server change affecting ability to send downloaded files???

am 08.08.2009 02:20:39 von Jerry Wilborn

--0016e645b94496e9c6047096529b
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

The 500 is the result of the missing content-type in the real header. Once
you get a blank line in there, it thinks thats the content. The error log
will likely say 'premature end of script headers'... Good mystery on why
it's got the blank line though.

Jerry Wilborn
jerrywilborn@gmail.com


On Fri, Aug 7, 2009 at 7:16 PM, Ben Dunlap wrote:

> > Very interesting. Excellent debugging advice. It's giving me a 500
> > error, probably why the Rackspace techs told me to check my code:
> >
> > HTTP/1.0 500 Internal Server Error
>
> Did you get that 500 while running curl from a machine outside of
> Rackspace's
> network?
>
> If so, I'd be interested to see what you get if you run it from the
> server's
> command line (using 'localhost' in the URL you pass to curl).
>
> Have you checked your Apache error log as well, and PHP's? There will
> usually
> be more detail in those locations when the server sends a 500.
>
> Ben
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--0016e645b94496e9c6047096529b--

Re: Server change affecting ability to send downloaded files???

am 08.08.2009 16:00:26 von Brian Dunning

A Rackspace guy determined that php.ini was set to use 16MB of memory,
and he upped it to 32MB, and now everything works. Some of my
downloads are as large as 41MB so I asked him to up it to 48MB.

Maybe they upgraded the PHP version or something and wiped this
setting. The 41MB files had always been downloading to customers
before, without any problem -- is there some way that could have
worked with php.ini set to 16MB, or does this mean for sure that the
setting was changed somehow?


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Server change affecting ability to send downloaded files???

am 08.08.2009 17:16:26 von Jerry Wilborn

--0016e644de962456900470a2d6a4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

http://us2.php.net/readfile

Returns the number of bytes read from the file. If an error occurs, FALSE is
> returned and unless the function was called as @readfile(), an error message
> is printed.


Ah. So readfile() was generating some error and outputting before the
Content-Type was sent to the browser. It might not hurt to move to a
fread($fh, 8096) + print() to prevent the bug in the future.

Jerry Wilborn
jerrywilborn@gmail.com


On Sat, Aug 8, 2009 at 9:00 AM, Brian Dunning wrote:

> A Rackspace guy determined that php.ini was set to use 16MB of memory, and
> he upped it to 32MB, and now everything works. Some of my downloads are as
> large as 41MB so I asked him to up it to 48MB.
>
> Maybe they upgraded the PHP version or something and wiped this setting.
> The 41MB files had always been downloading to customers before, without any
> problem -- is there some way that could have worked with php.ini set to
> 16MB, or does this mean for sure that the setting was changed somehow?
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--0016e644de962456900470a2d6a4--

RE: Server change affecting ability to send downloaded files???

am 10.08.2009 13:31:13 von M.Ford

> -----Original Message-----
> From: Brian Dunning [mailto:brian@briandunning.com]
> Sent: 08 August 2009 01:04
> To: PHP General List
> Subject: Re: [PHP] Server change affecting ability to send
> downloaded files???
>=20
> Very interesting. Excellent debugging advice. It's giving me a 500
> error, probably why the Rackspace techs told me to check my code:
>=20
> HTTP/1.0 500 Internal Server Error
> Date: Sat, 08 Aug 2009 00:01:10 GMT
> Server: Apache/2.0.52 (Red Hat)
> X-Powered-By: PHP/5.2.10
> Content-Disposition: attachment; filename=3D"Installer.bin"
> Content-Length: 23223296
> Connection: close
> Content-Type: application/octet-stream
>=20
> I'm at a loss. Nothing changed in the code and it works for ZIP
> files.

I notice the X-Powered-By header shows you are running on PHP 5.2.10. This=
was released on 18-June-2009, so Rackspace must have upgraded your PHP ins=
tallation some time after that. I think it's a reasonable assumption that =
something is behaving differently in PHP 5.2.10 from how it did in whatever=
version you were running under before. You need to track down what that s=
omething is, and fix it!


Cheers!

Mike
--=20
Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,
Leeds Metropolitan University, C507, Civic Quarter Campus,=20
Woodhouse Lane, LEEDS,=A0 LS1 3HE,=A0 United Kingdom=20
Email: m.ford@leedsmet.ac.uk=20
Tel: +44 113 812 4730





To view the terms under which this email is distributed, please go to http:=
//disclaimer.leedsmet.ac.uk/email.htm

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php