Keep Server Online
If you find the Apache Lounge, the downloads and overall help useful, please express your satisfaction with a donation.
or
A donation makes a contribution towards the costs, the time and effort that's going in this site and building.
Thank You! Steffen
Your donations will help to keep this site alive and well, and continuing building binaries. Apache Lounge is not sponsored.
| |
|
 Topic: mod_proxy_html produces malformed chunked response |
|
| Author |
|
mhfrantz
Joined: 17 Jun 2010
Posts: 3
|
 Posted: Thu 17 Jun '10 22:04 Post subject: mod_proxy_html produces malformed chunked response |
 |
|
I'm using a plain vanilla configuration based on the following tutorial:
http://www.apachetutor.org/admin/reverseproxies
I'm finding that the response uses chunked encoding, as expected, but that the final chunk is never sent. Instead, I see a cr-lf without the expected ASCII zero that should accompany the final chunk. (Wireshark shows the actual packets captured via tcpdump.) In other words, the response looks like this:
| Code: | HTTP/1.1 200 OK\r\n
...
Content-Type: text/html;charset=utf-8\r\n
...
Transfer-Encoding: chunked\r\n
\r\n
123\r\n
<html>...</html>[total of 123 hexadecimal bytes]
\r\n
|
To indicate the final chunk, that last "\r\n" should be "0\r\n" according to my understanding of the chunked encoding spec.
I've tried a few different clients (browsers, curl), and the way they react is to wait for another chunk until a timeout (presumably keep-alive timeout) occurs, which seems to be five seconds in my case.
This only happens when proxying HTML, and only if the mod_proxy_html module is active. Proxying other content (e.g. jpg) seems to work fine.
Has anyone seen this? I looked around this forum and elsewhere, to no avail.
This is Apache 2.2.15 with mod_proxy_html 3.1.2. |
|
| Back to top |
|
mhfrantz
Joined: 17 Jun 2010
Posts: 3
|
| Posted: Fri 18 Jun '10 19:16 Post subject: |
|
|
Correction:
The output is a valid chunk, but the problem is that the final chunk is missing. I would expect the following (after the HTTP headers):
| Code: | 123\r\n
<html>...</html>[total of 123 hexadecimal bytes]
\r\n
0\r\n
\r\n
|
Follow-up:
After some GDB debugging, it appears that ap_http_chunk_filter never reaches the EOS processing where the final chunk would be inserted. It also appears that mod_proxy_html does not see EOS either. |
|
| Back to top |
|
mhfrantz
Joined: 17 Jun 2010
Posts: 3
|
| Posted: Fri 18 Jun '10 20:49 Post subject: |
|
|
Solved (I think):
I'm planning to submit a patch to mod_xml2enc, which seems to be responsible for the EOS being stripped. In version 1.0.3 of this module, we see the following around line 403:
| Code: | if (APR_BUCKET_IS_EOS(b)) {
/* send remaining data */
return ap_fflush(f->next, ctx->bbnext);
|
The solution seems to be to add the EOS bucket to bbnext:
| Code: | if (APR_BUCKET_IS_EOS(b)) {
/* send remaining data */
APR_BRIGADE_INSERT_TAIL(ctx->bbnext,
apr_bucket_eos_create(f->r->connection->bucket_alloc));
return ap_fflush(f->next, ctx->bbnext);
|
|
|
| Back to top |
|
Steffen
Moderator
Joined: 15 Oct 2005
Posts: 3092
Location: Hilversum, NL, EU
|
| Posted: Fri 18 Jun '10 21:13 Post subject: |
|
|
I contacted Nick (author) to look at you post here.
Steffen |
|
| Back to top |
|
niq
Joined: 11 Aug 2007
Posts: 6
|
| Posted: Fri 18 Jun '10 22:23 Post subject: |
|
|
Thanks for pointing me to this. It's another facet of a bug I encountered a few weeks ago[1] (someone else had a problem). I was able to fix his problem with a trivial patch, but dropped the ball on working through it.
Your patch is not the same as mine (though almost as trivial). It's certainly doing the right thing (I can remember enough from before to know that), though I shall still need to evaluate it.
Please bug me if I drop the ball again!
[1] http://marc.info/?t=127236917600002&r=1&w=2 |
|
| Back to top |
|
|
|
|
|
|
