Well, so much for benefit of the doubt... -Ross.
On Fri, Mar 27, 2009 at 11:49 AM, Jonathan Rochkind <rochk...@jhu.edu> wrote: > 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 > _______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
