* on the Wed, Mar 07, 2007 at 01:50:18PM -0500, Jack Saunders wrote:
>>> This was on the dev list. I've brought it onto the users list as I no
>>> longer think it's a bug as such. Please see my original email above, and
>>> my update below for the issue.
>>>
>>> Right. I've made a *little* progress. Reading the core docs I found:
>>>
>>> "The AllowEncodedSlashes directive allows URLs which contain encoded path
>>> separators (%2F for / and additionally %5C for \ on according systems)
>>> to be used. Normally such URLs are refused with a 404 (Not found)
>>> error."
>>>
>>> So these requests are being 404'd simply for containing %2F's in the
>>> path. When I turn on encoded slashes with:
>>>
>>> AllowEncodedSlashes On
>>>
>>> It starts to proxy. But it starts to proxy the wrong thing
>>>
>>> Requests for:
>>>
>>> https://the.domain/session/session_id/MessagePart/INBOX%2FArchive/message_id/filename.txt
>>>
>>> Get proxied to:
>>>
>>>
>>> https://127.0.0.1:9100/session/session_id/MessagePart/INBOX/Archive/message_id/filename.txt
>>>
>>> I need it to be proxied to:
>>>
>>>
>>> https://127.0.0.1:9100/session/session_id/MessagePart/INBOX%2FArchive/message_id/filename.txt
>>>
>>> Where do I go from here?
>> I've sorted this now. Using a combination of AllowEncodedSlashes,
>> mod_rewrite and an external script called as a RewriteMap to change /'s
>> to %2F's. A horrible, unholy hack, but it works.
> I was running into the exact same issue with proxying to a lotus
> Workplace (Quickplace) application. Can you give me more indepth
> information on how you resolved this.
Hi Jack. It's a horrible hack but it works for me. You'll need to make
some changes obviously to get it to work for you, but hopefully this'll
point you in the right direction...
The original request:
https://the.domain/session/session_id/MessagePart/INBOX%2FArchive/message_id/filename.txt
What I wanted that to proxy to:
https://127.0.0.1:9100/session/session_id/MessagePart/INBOX%2FArchive/message_id/filename.txt
Now, you'd think that would be fairly easy wouldn't you? ;) Apache returned
404 before it even got to mod_proxy because the URL contained %2F. So I
turned on the AllowEncodedSlashes directive. See
http://httpd.apache.org/docs/2.0/mod/core.html#allowencodedslashes for a
description of the default %2F behaviour, and how AllowEncodedSlashes
changes that.
Enabling that option then meant that the request was getting to
mod_proxy. However, mod_proxy was seeing
"/session/session_id/MessagePart/INBOX/Archive/message_id/filename.txt"
rather than
"/session/session_id/MessagePart/INBOX%2FArchive/message_id/filename.txt"
I needed to maintain the encoded forward slashes. So instead of using
mod_proxy for these particular requests directly, I set up a mod_rewrite
rule. I needed to split the path into three parts, and encode the middle
part, then stick them back together, before proxying using mod_rewrite:
Part1: /session/session_id/MessagePart/
Part2: Bit to be encoded
Part3: message_id/filename.txt
I wrote an external script to be used with RewriteMap to encode the
middle part:
=======================================================================
#!/usr/bin/perl
$|=1;
while(<STDIN>){
s/\//\%2F/g;
print;
}
=======================================================================
I then defined the RewriteMap for the script:
RewriteMap encode_slashes prg:/etc/httpd/conf.d/rewrite_slashes.pl
I then added the following rewrite rules:
RewriteCond %{REQUEST_URI} ^/session/[^/]+/MessagePart/
RewriteRule ^proxy:(https://127.0.0.1:9100/session/[^/]+/MessagePart/)(.+)(/[^/]+/[^/]+)$ $1${encode_slashes:$2}$3 [P]
Hope this helps,
Mike
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|