[Mono-dev] Patch for HttpRequest.cs

Juraj Skripsky js at hotfeet.ch
Mon May 8 07:41:56 EDT 2006


Hello,

I was talking about the encoding used during the URL decoding only. My
patch fixes that. Running the attached test program demonstrates the
need to call HttpUtility.UrlDecode with Latin1 encoding to match MS
behaviour. No matter what encoding is set in
HttpRequest.ContentEncoding, MS.NET always URL decodes "%e4" to "ä", so
it must _always_ be calling

HttpUtility.UrlDecode("%e4", Encoding.GetEncoding("latin1"))

Or am I missing something? Any feedback appreciated!

- Juraj


On Mon, 2006-05-08 at 12:57 +0200, Kornél Pál wrote:
> Hi,
> 
> You are wrong. HttpRequest.QueryString does the following on MS.NET:
> 
> The only encoding it uses is HttpRequest.ContentEncoding. It tries to obtain 
> HttpWorkerRequest.GetQueryStringRawBytes(). If it fails then falls back to 
> HttpWorkerRequest.GetQueryString(). When it was able to obtain the byte 
> array it will decode it using HttpRequest.ContentEncoding.GetString(). As 
> such query string is decoded correctly. When no byte array is available in 
> HttpWorkerRequest or the query string was set either in constructor or using 
> HttpContext.RewritePath for example the string is assumed to be decoded 
> correctly so no decoding is done.
> 
> Now we have a string that still may be URL encoded. MS.NET probably calls 
> HttpUtility.UrlDecode just like we do but MS.NET passes 
> HttpRequest.ContentEncoding as well because query string is assumed to be 
> URL encoded using that encoding.
> 
> Note that obtaining query string from HttpWorkerRequest in the constructor 
> as we currently do is a wrong implementation as HttpRequest.ContentEncoding 
> can be changed before HttpRequest.QueryString is first accessed.
> 
> We should do the following:
> - delay query string processing until it is needed (don't obtain query 
> string in the constructor)
> - try HttpWorkerRequest.GetQueryStringRawBytes() as well
> - use HttpRequest.ContentEncoding to decode the byte array and for 
> HttpUtility.UrlDecode
> 
> Kornél
> 
> ----- Original Message ----- 
> From: "Juraj Skripsky" <js at hotfeet.ch>
> To: "Miguel de Icaza" <miguel at ximian.com>
> Cc: <mono-devel-list at lists.ximian.com>
> Sent: Monday, May 08, 2006 12:22 PM
> Subject: Re: [Mono-dev] Patch for HttpRequest.cs
> 
> 
> > Hello,
> >
> > After running more tests, I've found out that on MS.NET the decoding in
> > HttpRequest.QueryString does _not_ depend on
> > HttpRequest.ContentEncoding. In fact, MS seems to be always using Latin1
> > here. All other standard encodings fail.
> >
> > A revised patch is attached, including a NUnit test case. If no one
> > objects, I'll commit.
> >
> > - Juraj
> >
> >
> > On Sat, 2006-05-06 at 13:47 -0400, Miguel de Icaza wrote:
> >> Hello Juraj,
> >>
> >> > The attached patch makes sure that the get-parameters in QueryString 
> >> > are
> >> > url-decoded using the proper encoding (when creating the
> >> > NameValueCollection).
> >> >
> >> > May I commit?
> >>
> >> Could you provide NUnit tests for this case?
> >>
> >> Miguel
> >>
> >
> 
> 
> --------------------------------------------------------------------------------
> 
> 
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> > 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: requesttest.cs
Type: text/x-csharp
Size: 846 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060508/4b54d2bd/attachment.bin 


More information about the Mono-devel-list mailing list