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