I tested it out in IE with manually entering it in the location bar. At least in IE6, if you enter a < manually in a query string in the location bar, IE will send it along in the HTTP request as is, without escaping it.

(Which made it a lot easier to create a test case to make sure I had it taken care of!)

Ross Singer wrote:
Actually, I think the condition was that these URLs were being created
in Javascript and injected into the location header.  I'm not sure
that either of these browsers (IE or Safari) don't do the right thing
when < or > are entered in the location bar.  I do know for a fact,
however, that the condition Jonathan is talking about is because the
vendor is doing a redirect in javascript (because I first brought it
up 2 1/2 years ago:
http://thread.gmane.org/gmane.comp.lang.ruby.mongrel.general/1107/focus=1179).

-Ross.

On Thu, Mar 26, 2009 at 4:41 PM, Jonathan Rochkind <rochk...@jhu.edu> wrote:
Oh, and PS, I know that IE6 sends those. Because I discovered it. Safari
does too, for that matter. If they are (illegaly) in a URL in HTML or
entered in the location bar, etc.
My particular case in fact involved URLs in HTML (produced by a third party,
but targetting my app) delivered to an ordinary user agent like IE6 or
Firefox or Safari.  Firefox would happily correct them before sending them
to the server.  IE6 and Safari, no.

This is what I reported like a year and a half ago, and was told it wasn't
mongrel's problem. And brought up again like four months ago, to see if with
different developers you'd have a different opinion, and was again told it
wasn't mongrel's problem.

I guess someone with more pull than me found it inconvenient?

Jonathan

Eric Wong wrote:
Jonathan Rochkind <rochk...@jhu.edu> wrote:

My problem was with invalid query strings being sent to me by a vendor,
 not with problems in the header. So it won't be _exactly_ the same. I'm
 not sure if an apache rewrite map can change headers or not; it can  change
path/query string, which is all I needed. But I can show you what  I did, in
case it gives you ideas. It was a bit of a pain to figure out.

And here's the simple Perl script that replaced illegal chars in URL
 path/query string:

http://umlaut.rubyforge.org/svn/trunk/script/umlaut/rewrite_map.pl

These two those are no longer needed with the SVN version (which
we currently run in production on a pretty heavy site).  I think
it was IE6 sending them and we can't ignore IE6 :<

       s/>/%3E/g;
       s/</%3C/g;

Unfortunately I don't think it made the 1.1.5 release


 http://mongrel.rubyforge.org/browser/trunk/ext/http11/http11_parser.c?rev=996

I don't think I ever saw Mongrel error out on these.  Is your vendor
really that brain damaged?
       s/\//%2F/g;
       s/\\/%5C/g;

But man, this just creeps me out:
 s/ /\+/g;

ps: "tr/ /+/;" should be a tick faster than "s/ /\+/g;" :)


_______________________________________________
Mongrel-users mailing list
Mongrel-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-users

_______________________________________________
Mongrel-users mailing list
Mongrel-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-users

_______________________________________________
Mongrel-users mailing list
Mongrel-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-users

Reply via email to