You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by og...@yahoo.com on 2005/11/12 20:33:51 UTC
[users@httpd] mod_rewrite decodes %20 -> 400 bad request
Hello,
I'm using mod_rewrite with httpd 1.3.34 and am having some difficulties
with it when the URL that is getting rewritten has spaces (encoded as
%20) in it. Example:
http://simpy.com/user/otis/search/foo%20bar
The error I get is "400 bad Request":
Bad Request
Your browser sent a request that this server could not understand.
The request line contained invalid characters following the protocol
string.
My rewrite rule looks like this:
RewriteRule ^/user/(.*)/search/(.*)$
/simpy/User.do?username=$1&q=$2 [P,NE]
And what I see in my access_log is:
... "GET /simpy/User.do?username=otis&q=foo bar HTTP/1.1" ...
^^^^^^^
The problem seems to be that space in "foo bar".
I believe I need to tell httpd/rewrite module _not_ to decode the %20
from the original URL.
Does anyone know how I could configure mod_rewrite so that the %20 gets
preserved instead of converted to spaces?
Any help would be greatly appreciated. I just discovered this problem
on Simpy.com production site.
Thanks,
Otis
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] mod_rewrite decodes %20 -> 400 bad request
Posted by og...@yahoo.com.
Hello André,
--- André Malo <nd...@perlig.de> wrote:
> * <og...@yahoo.com> wrote:
>
> > Hi,
> >
> > I "solved" this problem by substituting "%20" with "+" characters.
> > Apparently, mod_rewrite doesn't convert "+" to spaces as it does
> with
> > "%20".
>
> Your "problem" is home-made. mod_rewrite always works on the
> unescaped
> URI-path and you're explicitly specifying by using [NE] that no
> escaping
> on the final string should be done. So you end up with unescaped
> characters
> in this final string (not only spaces will be a problem).
Actually, that [NE] was there only temporarily. I added it while I was
trying to tell mod_rewrite _not_ to decode %20 to a space.
I tried it with and without [NE], and it worked the same way in both
situation, translating %20 to a space, and causing 400 Bad Request.
> > I say "solved", as this is a hack, and I hate hacks... :(
>
> Ha! Then mod_rewrite shouldn't is not a tool for you at all ;-)
:)
Maybe, but it's the best tool around for this type of stuff, as far as
I know.
Otis
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] mod_rewrite decodes %20 -> 400 bad request
Posted by Robert Ionescu <ro...@googlemail.com>.
ogjunk-httpd1@yahoo.com wrote:
> Changing from [P] to [PT] also solved the issue with %20 being decoded
> to a space before dispatching the request to the rewritten URL (what
> the subject describes).
Because no ProxyPass is used anymore, but it was/is a bug:
http://issues.apache.org/bugzilla/show_bug.cgi?id=11265 (mod_rewrite
fails to encode special characters)
--
Robert
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] mod_rewrite decodes %20 -> 400 bad request
Posted by og...@yahoo.com.
Hi,
To wrap up this thread and for the archives:
Changing from [P] to [PT] also solved the issue with %20 being decoded
to a space before dispatching the request to the rewritten URL (what
the subject describes).
Consequently, this now works beautifully:
http://simpy.com/user/otis/search/apache%20%20%20httpd
Again, thanks for helping me through this.
Otis
--- ogjunk-httpd1@yahoo.com wrote:
> Hi,
>
> --- Robert Ionescu <ro...@googlemail.com> wrote:
>
> > ogjunk-httpd1@yahoo.com wrote:
> > > One more thing....
> > >
> > > --- André Malo <nd...@perlig.de> wrote:
> > >
> > >> * <og...@yahoo.com> wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> I "solved" this problem by substituting "%20" with "+"
> > characters.
> > >>> Apparently, mod_rewrite doesn't convert "+" to spaces as it
> does
> > >> with
> > >>> "%20".
> > >> Your "problem" is home-made. mod_rewrite always works on the
> > >> unescaped
> > >> URI-path and you're explicitly specifying by using [NE] that no
> > >> escaping
> > >> on the final string should be done. So you end up with unescaped
> > >> characters
> > >> in this final string (not only spaces will be a problem).
> > >
> > > Just to make sure I got this - are you saying that if I remove
> [NE]
> > > from the RewriteRule, then mod_rewrite will NOT convert %20 in a
> > > requested URI to a space?
> >
> > NE=no escape. mod_rewrite will not escape the output, meaning the
> > substitution /bar?arg=P1\%3dTest would usually become
> > /bar?arg=P1%253dTest (% is encoded into %25, and the NE-Flag
> prevents
> > this).
> >
> > > Try this:
> > > http://simpy.com/user/otis/search/apache%20httpd
> > >
> > > That URL is handled by the following RewriteRule:
> > >
> > > RewriteRule ^/user/(.*)/search/(.*)$
> > > /simpy/User.do?username=$1&q=$2 [P,env=URR:1]
> >
> > What I also asked you about in the newsgroup
> > alt.apache.configuration:
> > Why are you using the proxy-Flag ([P]). There is nothing to proxy
> > here,
> > because no protocol + host is given. So why don't you use just
> >
> > RewriteRule ^/user/(.*)/search/(.*)$
> /simpy/User.do?username=$1&q=$2
> > [L,env=URR:1]
> >
> > I tested both rules an apache 1.3.33, the one with the P-Flag
> returns
> > a
> > 400, without a 200.
> >
> > > This results in the following request under the hood:
> > > GET /simpy/User.do?username=otis&q=apache httpd HTTP/1.1" 400 369
> > "-"
> > > "-"
> > > ^^^^^^^^^^^^
> >
> > Usually the original request should be logged,
> > /user/otis/search/apache
> > httpd, not the one you're rewriting to. I think it's caused by the
> > P-Flag.
>
>
> I tried it with [L], but hit a 404.
> I think that is because with [L] Apache/mod_rewrite is not aware of
> the
> fact that the URL that I rewrite _to_ (e.g. /simpy/User.do?.....) is
> actually a mod_jk mapping for the Servlet engine:
>
> <IfModule mod_jk.c>
> JKWorkersFile "/usr/local/apache/conf/workers.properties"
> JKLogFile "/usr/local/apache/logs/mod_jk.log"
> JKLoglevel error
> JKMount /simpy/* ajp13
> </IfModule>
>
> So, with [L] Apache/mod_rewrite think that /simpy/User.do?.... s a
> real
> URL, they try to go there and, of course, find nothing, and return a
> 404.
>
> Here is the info from RewriteLog:
> (slightly different rewrite rule: /people --> /simpy/People.do)
>
> 127.0.0.1 - - [20/Nov/2005:19:59:19 -0500]
> [127.0.0.1/sid#958505c][rid#958d6b4/initial] (2) init rewrite engine
> with requested uri /people
> 127.0.0.1 - - [20/Nov/2005:19:59:19 -0500]
> [127.0.0.1/sid#958505c][rid#958d6b4/initial] (3) applying pattern
> '^/people(\/?)$' to uri '/people'
> 127.0.0.1 - - [20/Nov/2005:19:59:19 -0500]
> [127.0.0.1/sid#958505c][rid#958d6b4/initial] (2) rewrite /people ->
> /simpy/People.do
> 127.0.0.1 - - [20/Nov/2005:19:59:19 -0500]
> [127.0.0.1/sid#958505c][rid#958d6b4/initial] (2) local path result:
> /simpy/People.do
> 127.0.0.1 - - [20/Nov/2005:19:59:19 -0500]
> [127.0.0.1/sid#958505c][rid#958d6b4/initial] (1) go-ahead with
> /simpy/People.do [OK]
>
> 127.0.0.1 - - [20/Nov/2005:19:59:19 -0500]
> [127.0.0.1/sid#958505c][rid#958e5d4/initial/redir#1] (2) init rewrite
> engine with requested uri /people
> 127.0.0.1 - - [20/Nov/2005:19:59:19 -0500]
> [127.0.0.1/sid#958505c][rid#958e5d4/initial/redir#1] (3) applying
> pattern '^/people(\/?)$' to uri '/people'
> 127.0.0.1 - - [20/Nov/2005:19:59:19 -0500]
> [127.0.0.1/sid#958505c][rid#958e5d4/initial/redir#1] (2) rewrite
> /people -> /simpy/People.do
> 127.0.0.1 - - [20/Nov/2005:19:59:19 -0500]
> [127.0.0.1/sid#958505c][rid#958e5d4/initial/redir#1] (2) local path
> result: /simpy/People.do
> 127.0.0.1 - - [20/Nov/2005:19:59:19 -0500]
> [127.0.0.1/sid#958505c][rid#958e5d4/initial/redir#1] (1) go-ahead
> with
> /simpy/People.do [OK]
>
>
> I then tried with both [P] and [PT].
> Both of these result in a 200 (OK), which is good!
> [P] resulted in both request URIs to be logged:
> /people
> AND
> /simpy/People.do
>
> (this is why I used that env URR=1 hack to do conditional logging and
> log only one of those hits (the latter))
>
> [PT] resulted in only the "pretty" request URI being logged:
> /people
>
> This makes [PT] more attractive.
>
>
> BUUUUUUT, [PT] looked even more attractive to me when I looked at the
> RewriteLog log - with [P] the request went through a 2-part phase,
> where first the request URI /people would be matched to
> /simpy/People.do....., and then the /simpy/People.do request would be
> processed and passed through, because it wouldn't match any rules.
>
> In short, this is my conclusion:
>
> [L] doesn't work for me (404), because the URL rewritten _to_ is not
> a
> URL for a static file, but rather a webapp/servlet engine mapping
>
> [P] works (200), but logs both URLs (pretty one and the one rewritten
> to), and it also involves more request processing
>
> [PT] works (200), logs only 1 request URL (the pretty one), and it
> involves less request processing than [P]
>
>
> Robert and André - thank you for your help and please correct me if
> I'm
> wrong - I'm not new to httpd, but I am new to URL rewriting.
>
> Thanks,
> Otis
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Simpy -- http://www.simpy.com/ -- Find it. Tag it. Share it.
>
> ---------------------------------------------------------------------
> 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@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] mod_rewrite decodes %20 -> 400 bad request
Posted by og...@yahoo.com.
Hi,
--- Robert Ionescu <ro...@googlemail.com> wrote:
> ogjunk-httpd1@yahoo.com wrote:
> > One more thing....
> >
> > --- André Malo <nd...@perlig.de> wrote:
> >
> >> * <og...@yahoo.com> wrote:
> >>
> >>> Hi,
> >>>
> >>> I "solved" this problem by substituting "%20" with "+"
> characters.
> >>> Apparently, mod_rewrite doesn't convert "+" to spaces as it does
> >> with
> >>> "%20".
> >> Your "problem" is home-made. mod_rewrite always works on the
> >> unescaped
> >> URI-path and you're explicitly specifying by using [NE] that no
> >> escaping
> >> on the final string should be done. So you end up with unescaped
> >> characters
> >> in this final string (not only spaces will be a problem).
> >
> > Just to make sure I got this - are you saying that if I remove [NE]
> > from the RewriteRule, then mod_rewrite will NOT convert %20 in a
> > requested URI to a space?
>
> NE=no escape. mod_rewrite will not escape the output, meaning the
> substitution /bar?arg=P1\%3dTest would usually become
> /bar?arg=P1%253dTest (% is encoded into %25, and the NE-Flag prevents
> this).
>
> > Try this:
> > http://simpy.com/user/otis/search/apache%20httpd
> >
> > That URL is handled by the following RewriteRule:
> >
> > RewriteRule ^/user/(.*)/search/(.*)$
> > /simpy/User.do?username=$1&q=$2 [P,env=URR:1]
>
> What I also asked you about in the newsgroup
> alt.apache.configuration:
> Why are you using the proxy-Flag ([P]). There is nothing to proxy
> here,
> because no protocol + host is given. So why don't you use just
>
> RewriteRule ^/user/(.*)/search/(.*)$ /simpy/User.do?username=$1&q=$2
> [L,env=URR:1]
>
> I tested both rules an apache 1.3.33, the one with the P-Flag returns
> a
> 400, without a 200.
>
> > This results in the following request under the hood:
> > GET /simpy/User.do?username=otis&q=apache httpd HTTP/1.1" 400 369
> "-"
> > "-"
> > ^^^^^^^^^^^^
>
> Usually the original request should be logged,
> /user/otis/search/apache
> httpd, not the one you're rewriting to. I think it's caused by the
> P-Flag.
I tried it with [L], but hit a 404.
I think that is because with [L] Apache/mod_rewrite is not aware of the
fact that the URL that I rewrite _to_ (e.g. /simpy/User.do?.....) is
actually a mod_jk mapping for the Servlet engine:
<IfModule mod_jk.c>
JKWorkersFile "/usr/local/apache/conf/workers.properties"
JKLogFile "/usr/local/apache/logs/mod_jk.log"
JKLoglevel error
JKMount /simpy/* ajp13
</IfModule>
So, with [L] Apache/mod_rewrite think that /simpy/User.do?.... s a real
URL, they try to go there and, of course, find nothing, and return a
404.
Here is the info from RewriteLog:
(slightly different rewrite rule: /people --> /simpy/People.do)
127.0.0.1 - - [20/Nov/2005:19:59:19 -0500]
[127.0.0.1/sid#958505c][rid#958d6b4/initial] (2) init rewrite engine
with requested uri /people
127.0.0.1 - - [20/Nov/2005:19:59:19 -0500]
[127.0.0.1/sid#958505c][rid#958d6b4/initial] (3) applying pattern
'^/people(\/?)$' to uri '/people'
127.0.0.1 - - [20/Nov/2005:19:59:19 -0500]
[127.0.0.1/sid#958505c][rid#958d6b4/initial] (2) rewrite /people ->
/simpy/People.do
127.0.0.1 - - [20/Nov/2005:19:59:19 -0500]
[127.0.0.1/sid#958505c][rid#958d6b4/initial] (2) local path result:
/simpy/People.do
127.0.0.1 - - [20/Nov/2005:19:59:19 -0500]
[127.0.0.1/sid#958505c][rid#958d6b4/initial] (1) go-ahead with
/simpy/People.do [OK]
127.0.0.1 - - [20/Nov/2005:19:59:19 -0500]
[127.0.0.1/sid#958505c][rid#958e5d4/initial/redir#1] (2) init rewrite
engine with requested uri /people
127.0.0.1 - - [20/Nov/2005:19:59:19 -0500]
[127.0.0.1/sid#958505c][rid#958e5d4/initial/redir#1] (3) applying
pattern '^/people(\/?)$' to uri '/people'
127.0.0.1 - - [20/Nov/2005:19:59:19 -0500]
[127.0.0.1/sid#958505c][rid#958e5d4/initial/redir#1] (2) rewrite
/people -> /simpy/People.do
127.0.0.1 - - [20/Nov/2005:19:59:19 -0500]
[127.0.0.1/sid#958505c][rid#958e5d4/initial/redir#1] (2) local path
result: /simpy/People.do
127.0.0.1 - - [20/Nov/2005:19:59:19 -0500]
[127.0.0.1/sid#958505c][rid#958e5d4/initial/redir#1] (1) go-ahead with
/simpy/People.do [OK]
I then tried with both [P] and [PT].
Both of these result in a 200 (OK), which is good!
[P] resulted in both request URIs to be logged:
/people
AND
/simpy/People.do
(this is why I used that env URR=1 hack to do conditional logging and
log only one of those hits (the latter))
[PT] resulted in only the "pretty" request URI being logged:
/people
This makes [PT] more attractive.
BUUUUUUT, [PT] looked even more attractive to me when I looked at the
RewriteLog log - with [P] the request went through a 2-part phase,
where first the request URI /people would be matched to
/simpy/People.do....., and then the /simpy/People.do request would be
processed and passed through, because it wouldn't match any rules.
In short, this is my conclusion:
[L] doesn't work for me (404), because the URL rewritten _to_ is not a
URL for a static file, but rather a webapp/servlet engine mapping
[P] works (200), but logs both URLs (pretty one and the one rewritten
to), and it also involves more request processing
[PT] works (200), logs only 1 request URL (the pretty one), and it
involves less request processing than [P]
Robert and André - thank you for your help and please correct me if I'm
wrong - I'm not new to httpd, but I am new to URL rewriting.
Thanks,
Otis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/ -- Find it. Tag it. Share it.
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] mod_rewrite decodes %20 -> 400 bad request
Posted by Robert Ionescu <ro...@googlemail.com>.
ogjunk-httpd1@yahoo.com wrote:
> One more thing....
>
> --- André Malo <nd...@perlig.de> wrote:
>
>> * <og...@yahoo.com> wrote:
>>
>>> Hi,
>>>
>>> I "solved" this problem by substituting "%20" with "+" characters.
>>> Apparently, mod_rewrite doesn't convert "+" to spaces as it does
>> with
>>> "%20".
>> Your "problem" is home-made. mod_rewrite always works on the
>> unescaped
>> URI-path and you're explicitly specifying by using [NE] that no
>> escaping
>> on the final string should be done. So you end up with unescaped
>> characters
>> in this final string (not only spaces will be a problem).
>
> Just to make sure I got this - are you saying that if I remove [NE]
> from the RewriteRule, then mod_rewrite will NOT convert %20 in a
> requested URI to a space?
NE=no escape. mod_rewrite will not escape the output, meaning the
substitution /bar?arg=P1\%3dTest would usually become
/bar?arg=P1%253dTest (% is encoded into %25, and the NE-Flag prevents this).
> Try this:
> http://simpy.com/user/otis/search/apache%20httpd
>
> That URL is handled by the following RewriteRule:
>
> RewriteRule ^/user/(.*)/search/(.*)$
> /simpy/User.do?username=$1&q=$2 [P,env=URR:1]
What I also asked you about in the newsgroup alt.apache.configuration:
Why are you using the proxy-Flag ([P]). There is nothing to proxy here,
because no protocol + host is given. So why don't you use just
RewriteRule ^/user/(.*)/search/(.*)$ /simpy/User.do?username=$1&q=$2
[L,env=URR:1]
I tested both rules an apache 1.3.33, the one with the P-Flag returns a
400, without a 200.
> This results in the following request under the hood:
> GET /simpy/User.do?username=otis&q=apache httpd HTTP/1.1" 400 369 "-"
> "-"
> ^^^^^^^^^^^^
Usually the original request should be logged, /user/otis/search/apache
httpd, not the one you're rewriting to. I think it's caused by the P-Flag.
--
Robert
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] mod_rewrite decodes %20 -> 400 bad request
Posted by og...@yahoo.com.
One more thing....
--- André Malo <nd...@perlig.de> wrote:
> * <og...@yahoo.com> wrote:
>
> > Hi,
> >
> > I "solved" this problem by substituting "%20" with "+" characters.
> > Apparently, mod_rewrite doesn't convert "+" to spaces as it does
> with
> > "%20".
>
> Your "problem" is home-made. mod_rewrite always works on the
> unescaped
> URI-path and you're explicitly specifying by using [NE] that no
> escaping
> on the final string should be done. So you end up with unescaped
> characters
> in this final string (not only spaces will be a problem).
Just to make sure I got this - are you saying that if I remove [NE]
from the RewriteRule, then mod_rewrite will NOT convert %20 in a
requested URI to a space?
If that is what you are saying, then I think that is incorrect.
Try this:
http://simpy.com/user/otis/search/apache%20httpd
That URL is handled by the following RewriteRule:
RewriteRule ^/user/(.*)/search/(.*)$
/simpy/User.do?username=$1&q=$2 [P,env=URR:1]
This results in the following request under the hood:
GET /simpy/User.do?username=otis&q=apache httpd HTTP/1.1" 400 369 "-"
"-"
^^^^^^^^^^^^
Note the space between "apache" and "httpd".
On the other hand, this works:
http://simpy.com/user/otis/search/apache+httpd
Thanks,
Otis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/ -- Find it. Tag it. Share it.
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] mod_rewrite decodes %20 -> 400 bad request
Posted by André Malo <nd...@perlig.de>.
* <og...@yahoo.com> wrote:
> Hi,
>
> I "solved" this problem by substituting "%20" with "+" characters.
> Apparently, mod_rewrite doesn't convert "+" to spaces as it does with
> "%20".
Your "problem" is home-made. mod_rewrite always works on the unescaped
URI-path and you're explicitly specifying by using [NE] that no escaping
on the final string should be done. So you end up with unescaped characters
in this final string (not only spaces will be a problem).
> I say "solved", as this is a hack, and I hate hacks... :(
Ha! Then mod_rewrite shouldn't is not a tool for you at all ;-)
nd
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] mod_rewrite decodes %20 -> 400 bad request
Posted by og...@yahoo.com.
Hi,
I "solved" this problem by substituting "%20" with "+" characters.
Apparently, mod_rewrite doesn't convert "+" to spaces as it does with
"%20".
I say "solved", as this is a hack, and I hate hacks... :(
Is there a list/forum/anything focused on Apache modules or mod_rewrite
in particular?
Thanks,
Otis
--- ogjunk-httpd1@yahoo.com wrote:
> Hello,
>
> I'm using mod_rewrite with httpd 1.3.34 and am having some
> difficulties
> with it when the URL that is getting rewritten has spaces (encoded as
> %20) in it. Example:
> http://simpy.com/user/otis/search/foo%20bar
>
> The error I get is "400 bad Request":
>
> Bad Request
> Your browser sent a request that this server could not understand.
> The request line contained invalid characters following the protocol
> string.
>
> My rewrite rule looks like this:
>
> RewriteRule ^/user/(.*)/search/(.*)$
> /simpy/User.do?username=$1&q=$2 [P,NE]
>
>
> And what I see in my access_log is:
> ... "GET /simpy/User.do?username=otis&q=foo bar HTTP/1.1" ...
> ^^^^^^^
>
> The problem seems to be that space in "foo bar".
> I believe I need to tell httpd/rewrite module _not_ to decode the %20
> from the original URL.
>
> Does anyone know how I could configure mod_rewrite so that the %20
> gets
> preserved instead of converted to spaces?
>
> Any help would be greatly appreciated. I just discovered this
> problem
> on Simpy.com production site.
>
> Thanks,
> Otis
>
> ---------------------------------------------------------------------
> 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@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org