Mailing List Archive: Cherokee: users

X-Sendfile downloads get truncated sometimes (possibly IE only)

Index | Next | Previous | View Threaded

r.hartmann at wabnitz

Jun 29, 2011, 3:22 AM

Post #1 of 2 (373 views)
Permalink

X-Sendfile downloads get truncated sometimes (possibly IE only)

Hello,

we have a site running cherokee 1.2.2 behind pound 2.5 (to take care of
TLS) on debian squeeze.

The site consists of static files and PHP (5.3.3-7+squeeze1) only. The
vhost has 3 rules:

- Redirect Non-TLS to TLS
- Use FastCGI Backend (php-cgi) for php files
- Default: List & Send with I/O-Cache enabled

That means, cherokee takes external requests on port 80 only to redirect
them to 443 (pound).
Pound takes external requests on port 443 and uses localhost:80 to talk
to cherokee.

Keep-Alive and Chunked Encoding are both enabled (if that matters).

The site contains a file.php to take care of special file downloads.
After initially switching from nginx to cherokee, we've been running
into lots of trouble with that file.php and truncated downloads. Part of
that was solved using pound for TLS but there have still been issues
with specific files since file.php was piping files through PHP
completely.

After switching to X-Sendfile, everything looked good. However, we
received notice that some downloads are still being truncated every once
in a while. We have not been able to pinpoint the cause yet, but we have
only seen it happen with IE 8 (other versions could be affected too).

file.php produces 4 headers:

Content-Type: application/force-download
Content-Length: filesize($filepath)
Content-Disposition: attachment; filename="$filename"
X-Sendfile: $filepath

Sniffing the traffic between pound and cherokee revealed that
Content-Length is NOT being sent out by cherokee. Thus, the
client/browser does NOT know about the total filesize and cannot even
detect if the file was completely transferred or not.

Also, the transfer is gzipped (Content-Encoding: gzip) and cherokees
access.log reports differing sizes for the same file. Could that have to
do with gzip?

So that leaves three questions:

Why are downloads truncated sometimes?
Why does cherokee not send Content-Length although it is explicitly
given by the PHP backend?
Why are access logs reporting differing sizes for the same file?

Any ideas and/or suggestions?

Thanks in advance
Ringo
_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

alvaro at octality

Jul 12, 2011, 2:22 AM

Post #2 of 2 (318 views)
Permalink

Re: X-Sendfile downloads get truncated sometimes (possibly IE only) [In reply to]

Hello Ringo,

On Wed, Jun 29, 2011 at 12:22 PM, Ringo Hartmann <r.hartmann [at] wabnitz>wrote:
>
>
> After switching to X-Sendfile, everything looked good. However, we
> received notice that some downloads are still being truncated every once
> in a while. We have not been able to pinpoint the cause yet, but we have
> only seen it happen with IE 8 (other versions could be affected too).
>
> file.php produces 4 headers:
>
> Content-Type: application/force-download
> Content-Length: filesize($filepath)
> Content-Disposition: attachment; filename="$filename"
> X-Sendfile: $filepath
>
> Sniffing the traffic between pound and cherokee revealed that
> Content-Length is NOT being sent out by cherokee. Thus, the
> client/browser does NOT know about the total filesize and cannot even
> detect if the file was completely transferred or not.
>

Well, that depends on the complete response header. If it replied using
HTTP/1.0 or a "Connection: close" entry it'd be fine to skip the
Content-Length entry.

I'm logging a bug report for this <http://bugs.cherokee-project.com/1228>,
so we ensure it's checked out properly. Please, do not hesitate to add any
information about the issue (the complete response, for instance).

Why are downloads truncated sometimes?
>

Probably because of a bug, either in Cherokee, Pounce or IE8.

> Why does cherokee not send Content-Length although it is explicitly
> given by the PHP backend?
>

Most likely because the response will be GZip'ed, so the Content-Length you
sent is not longer valid.

> Why are access logs reporting differing sizes for the same file?
>

Because of a bug we fixed already in the latest versions. The temporal
buffers used for the compression changed its size from one request to the
next, so the compression was not always the same.

--
Greetings, alo
http://www.octality.com/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads