[SpamCop-List] Re: New link obfuscation?
Michael Lefevre
michael.spamcop at michaellefevre.com
Sun Mar 21 23:03:56 EST 2004
Philippe Verdy wrote:
> "GV" <nobody at spamcop.net> a écrit dans le message de
> news:c3kbpl$dqu$1 at news.spamcop.net...
>> And to be even more exact, RFC 1738 actually does not allow the
>> user:password@ for http URLs. I am still wondering where this is actually
>> introduced. The @ syntax for the login information applies basically only
> to
>> the ftp and telnet schemes. It is natural to use to also for http, but it
> is
>> still not compliant to RFC 1738 (or RFC 2616 HTTP/1.1)
>
> Please note that RFC-Editor.org lists:
>
> RFC1738 Uniform Resource Locators (URL), by T. Berners-Lee, L. Masinter,
> M. McCahill, December 1994,
[snip]
>
> So use now this RFC:
>
> RFC2396 Uniform Resource Identifiers (URI): Generic Syntax, by T.
> Berners-Lee, R. Fielding, L. Masinter, August 1998,
>
> which updates the two first RFC above.
Note that it _updates_ the first two (include 1738), it doesn't obsolete
them. That means that 1738 is still valid, except where it might be
contradicted by the newer RFC.
> So forget RFC1738 which never gained the "standard" status, but just the
> "proposed standard" status before being updated above...
No, don't forget it - it still defines HTTP URLs. RFC2396 is generic,
it's talking about URLs in general. RFC1738 (and the earlier RFCs) say
that HTTP can't have authentication stuff. RFC2396 only talks in general
terms, it doesn't add authentication into HTTP URLs. HTTP with usernames
and passwords have never been RFC-compliant - Netscape and then Microsoft
just decided to make their browsers interpret them I guess because, like
GV said, they felt it was a "natural" addition. Microsoft have now
removed it again, so they've actually increased their RFC compliance.
--
Michael
More information about the SpamCop-List
mailing list