[SpamCop-List] Re: New link obfuscation?
nobody at spamcop.net
Sun Mar 21 12:38:47 EST 2004
> Then you have this rule for the 4-components "generic URI" syntax:
> (where  mark the optional parts)
> So the next thing to parse in the <scheme-specific-part> is the first
> occurence of a '?' character to separate the query string from the URL.
> leaves the two components:
> As HTTP and HTTPS are hierarchic and have a <authority> component in their
> scheme, the next thing to recognize is the presence of a leading "//" to
> if there's an authority (the absence of the authority means that the URL
> must be resolved according to an unspecified "base", transported
> and not considered "opaque" as not resolvable without a context). So let's
> concentrate to the other case which is the "hier_part" in:
> absoluteURI = scheme ":" ( hier_part | opaque_part )
> hier_part = ( net_path | abs_path ) [ "?" query ]
> net_path = "//" authority [ abs_path ]
> abs_path = "/" path_segments
O.K. But that's the same what I said: The authority stands between a // and
a / or the end of the absoluteURI. An @ had no precedence because it is not
mentioned on this level, i.a.w.: http://server/@server2 refers to server and
the path_segment @server2
> Note that RFC 2616 describes only what can appear in a URL WITHOUT an
> authority, and uses only the format of the "abs_path" case for the
> "hier_part" rule above. It says nothing for the "net_path" case.
I know that. Therefore I refered to 1738 and only xrefed 2616 where it is
also mentioned... And still, everything you mentioned does not allow a /
there. It must be escaped. So still there is no violation of RFC by MS in IE
and it still parses the URL correctly...
More information about the SpamCop-List