the Network.URI parser (CORRECTION)

Peter Gammie peteg42 at gmail.com
Tue May 27 07:00:54 EDT 2008


Graham: Thanks for your sterling efforts here. I concur with your  
professional opinion. I will investigate what I can layer on top of  
your library.

cheers
peter

On 27/05/2008, at 3:52 PM, Graham Klyne wrote:

> Peter,
>
> [I should be more careful ... I meant RFC 3986, as in:]
>
> I haven't looked at this code in a while, but... as far as I'm aware  
> it's stable
> and reliable.  The parser was written to follow, as closely as I  
> could manage,
> the specification in RFC3986 (http://www.ietf.org/rfc/rfc3986.txt) -  
> experience
> in writing this parser was used as feedback (among many others) in the
> development of RFC2396.
>
> The parser does not attempt to be in any respect scheme-aware.  The  
> parentheses
> here are, as far as I'm aware, quite legitimate in a generic URI,  
> and I think no
> warning or refusal is appropriate for a generic URI parser.  (URIs  
> can be and
> are used in many places other than web pages.)
>
> However, there are additional constraints that may be appropriate  
> for specific
> URI schemes - maybe like reserving parentheses as you suggest - and  
> were I to
> implement these I would do so in a layer built upon the generic URI  
> parser:
> given the generic parse, a lookup on the scheme name could select an  
> additional
> validation function.
>
> #g
> --
>
> Peter Gammie wrote:
>> Hello,
>> I'm wondering what the state of this parser is.
>> It parses the contents of the src attribute in the following:
>> <p><img src="javascript:alert('XSS');" alt=""/></p>
>> which causes IE 5.5 (and probably 6) to show a dialog box. (I  
>> lifted this example from the list at http://ha.ckers.org/xss.html)
>> I was hoping the parser in Network.URI would choke on it - the  
>> parentheses are reserved, at least.
>> cheers
>> peter
>
> -- 
> Graham Klyne
> Contact info: http://www.ninebynine.org/#Contact
>
>
>



More information about the Libraries mailing list