5 ms·
that will be HTTP/1.3
by est 17y ago
that will be HTTP/1.3
- joshu 17y agoNo. It's a valid URL. Why would we require a new protocol version?
- jsn 17y agoUmm, because that valid URL uses "mailto" protocol, which doesn't support "GET" requests as you described?
- jrockway 17y agoActually, it uses HTTP with "mailto" as the username and "username" as the password.
- andreyf 17y agoThat's not part of HTTP 1.1, just a popular convention for URLs carried over from Telnet/FTP, see: http://www.w3.org/Addressing/rfc1738.txt http://www.w3.org/Addressing/rfc1738.txt
- joshu 17y agoWhere, specifically, RFC 2616 does the spec say you must specify a http URI? 5.1.2 just specifies that it's a RequestURI and does not further define it. 3.2 refers you to RFC 2396, the URI spec, which includes mailto. It's a valid URI and you are allowed to ask for it.
- andreyf 17y ago5.1.2 just specifies that it's a RequestURI and does not further define it. I'm not sure if I understand. The one I'm looking at further defines it as: Request-URI = "*" | absoluteURI | abs_path | authority Edit: ah, of which, absoluteURI refers to 3.2.1, which references RFC2396, which includes mailto. Still, doesn't include user:password@domain, though :-P Src: http://www.ietf.org/rfc/rfc2616.txt http://www.ietf.org/rfc/rfc2616.txt
- joshu 17y agouser:password@domain is a browser convention, not part of a URL, like I said.
- joshu 17y agoNo, the user@pass thing is a browser stuff. It's not sent as part of the request line.