It would appear that mod_proxy/http_proxy cannot forward byterange requests. Running Apache 2.0.40 on Linux 7.3 which Proxys back to IIS on Win2K - PDFs load fine from the Win2K server or from the Linux server when accessed directly. They come up blank (only when the client is running IE with Acroboat Reader 4.x) when going through the ProxyPass. Always works with Acrobat Reader 5.
I am seeing the same situation with Apache 2.0.40 and 2.0.39 on Linux 7.2 and 7.3. When using apache as a reverse proxy for a variety of web servers including iis4, iis5, apache 1.3.26, apache 1.3.22. I also see this only with client running IE and Acrobat 4.x. Likewise works fine with Acrobat Reader 5.x One additional not is that the failure occurs on pdf file greater than 32K. PDF files smaller than 32K seem to work.
Hello! I suppose that this is not Apache bug. More likely that your PDF files was not prepared for 'byteserving'. Please read full details on: http://www.adobe.com/support/techguides/acrobat/byteserve/byteserv03.html. My English is too poor to explain details myself. Best regards, Alexander Shishilov.
This is not resolved, nor fixed. The proxy is byteranging the response from the proxied server, which had already byteranged ITS response based on the proxy request. Simple solutions; we must either remove the HTTP_BYTERANGE filter from the proxy server, or drop the Range: header from the proxy request. The first breaks any other filters in the proxy request and makes the response uncachable. The later consumes additional bandwidth of the response isn't cached.
*** Bug 11618 has been marked as a duplicate of this bug. ***
>>The proxy is byteranging the response from the proxied server, >>which had already byteranged ITS response based on the proxy >>request. The proxy is byteranging the response, but the backend server is NOT sending byteranded response. Backend server should always send the full document whenever it receive the request from the proxy. But if PDF file was not prepared for byteserving correctly the client fails.
We had this problem a lot w/ 2.0.40 but it seems to have disappeared in our testing of 2.0.43. I've read the change logs and didn't notice anything matching this *exactly* but there did appear to be some changes to how streamed data is returned, which is often the case when serving PDFs. Curious thing, it seemed from the changes to fix had to do with mod_cache, which we've turned-off.
Reclassifying this as closed. We should be forwarding all proxy requests to the backend server without caching (we can't cache partial responses) and not manipulating the results. Further, in 2.0.44 we don't strip the C-L from the response either, IIRC, which is the basis for the Acrobat Viewer/IE bug. If proxy continues to demonstrate this misbehavior *with mod_cache disabled* in 2.0.44, please reopen the incident. If mod_cache changes (breaks) the expected behavior, please open a new incident for 'mod_cache interferes with proxied PDF byterange requests'.
I am seeing this situation in Apache 2.0.44. The server is configured as a reverse proxy using ProxyPass and ProxyPassReverse. When the client is running IE (5.x or 6.x) with Acrobat 5.x and request a pdf under 15-20 kb the acrobat plugin is launched and the result is a blank page. No problem with bigger pdf's. Tested with mod_cache enabled and disabled.
Created attachment 5584 [details] Workaround patch. No additional misbehavior detected.
We have a similiar problem that was originally filed as different bug and the nreclassified as this one. What we see is that any proxy requested that is chunked loses its Chunked Headers, chunk number and never has Content-Length added into the header stream. This results in all content of the request being lost. Bug : 11618 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11618 Thanks John-
We earlier reported a bug [11618] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11618 This bug was closed and pointed here. In this bug what happens is that anything using chunked encoding via mod_proxy is stripped of its chunk information and header however no Content-length header is added to the sub-request and thus the receiving server has no way and handling the data ( post without length ). This bug still occurs in the latest build of apache 2.x and was never resolved.
Note, it also occurs in 1.x as well, its not specific to 2.x
Fixed in 2.0.45: *) Don't remove the Content-Length from responses in mod_proxy PR: 8677 [Brian Pane]
The diff is basically the patch above ;) --- proxy_http.c.orig 2003-04-02 12:43:15.000000000 +0200 +++ proxy_http.c 2003-02-03 18:31:50.000000000 +0100 @@ -1,7 +1,7 @@ /* ==================================================================== * The Apache Software License, Version 1.1 * - * Copyright (c) 2000-2002 The Apache Software Foundation. All rights + * Copyright (c) 2000-2003 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without @@ -907,16 +907,12 @@ /* We need to copy the output headers and treat them as input * headers as well. BUT, we need to do this before we remove - * TE and C-L, so that they are preserved accordingly for + * TE, so that they are preserved accordingly for * ap_http_filter to know where to end. */ rp->headers_in = apr_table_copy(r->pool, r->headers_out); - /* In order for ap_set_keepalive to work properly, we can NOT - * have any length information stored in the output headers. - */ apr_table_unset(r->headers_out,"Transfer-Encoding"); - apr_table_unset(r->headers_out,"Content-Length"); ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r->server, "proxy: start body send");
Hi, If you wanna disable byterange transfert to enabled one-shot transfert of your PDF (and no more have your PDF blank) you can modify the Apache source code to force it send the "Accept-Range:" header to the "none" value (instead of "bytes" value). I've made a patch for the 1.3.27 version, it's surely applicable to all other version of Apache. Get it at http://www.rvbone.com/pdfpatch (use it with patch -p0 < pdfpatch at the apache-1.3.27 leveldir). Or modify directly with vi the src/main/http_core.c file: ap_table_setn(r->headers_out, "Accept-Ranges", "bytes"); change "bytes" with "none" ! Then recompile Apache. You have to do this modification on the target server, it's useless on the proxy server. It's just a tips, waiting for a real solution from Apache team !
The .45 release fixes it for the RESPONSE but not the REQUEST. So when my chunked query comes in from a client, the headers are stripped before the sub-request is made. This means that the backend server that I am ProxyPass'ing to gets a munged request that is useless since it has no content-length and has lost its chunking information.
In an effort to possibly get this bug resolved more quickly I am offering a $500 bounty for the first person to get a confirmed fix into the apache release. Once its verified fixed and in the source tree for release into the next version of the 2.x release we will send the bounty to you! Send email to siberian@siberian.org and I will get you my contact info so you can confirm offline that the bounty does indeed exist and we are serious about it. Cash cash cash cash!
I am seeing this bug in 2.0.47(frontend)and 1.3.27(backend) as well
We are seeing the issue with mod_proxy stripping both Transfer-Encoding and Content-Length from requests in Apache 2.0.52.
This is quite confusing: the comments indicate rather a lot of people discussing different behaviours, some fixed, some fixable by configuration. Not helped by listing 1.3, so those of us who search on 2.0 have never seen this report. * Byterange requests: the best solution is probably to use mod_headers to disable byteranges for proxied requests. Comment #3 suggests making apache do this automatically, but it's also easy for a server admin. Comment #7 indicates done. * Comment 10 introduces a different issue. Comments #13 and #16 follow up indicating part of the problem fixed. The remaining unfixed issue is reported, less confusingly, in Bug 15859. So to reduce confusion, I'm redirecting there. *** This bug has been marked as a duplicate of 15859 ***