[SpamCop-List] Re: New link obfuscation?

[GV]

Hi,

> Then you have this rule for the 4-components "generic URI" syntax:
>     <scheme>:[//<authority>][<path>][?query]
> (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.
This
> leaves the two components:
>     [//<authority>][<path>]
>
> 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
see
> if there's an authority (the absence of the authority means that the URL
> must be resolved according to an unspecified "base", transported
elsewhere,
> 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...

Gerald