- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 26 Nov 2015 07:54:10 +0100
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Nov 26, 2015 at 04:29:30PM +1100, Mark Nottingham wrote: > Now that we have RFC7686, there's a new requirement applicable to HTTP clients: > > """ > Applications (including proxies) that implement the Tor protocol MUST recognize .onion names as special by either accessing them directly or using a proxy (e.g., SOCKS [RFC1928]) to do so. Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion and SHOULD NOT perform a DNS lookup. > """ I'm surprized that an RFC on standards track managed to redefine how non-interested implementations must behave : - there's this paragraph that you quoted above which affects perfectly standards-compliant applications - standards-compliant name resolution APIs and resolvers are now required to respond with NXDOMAIN if they don't implement the spec - caching DNS servers must be modified - authoritative servers must respond with NXDOMAIN - etc etc ... Normally they only define the behaviour for compliant ones. I smell a massive mess here. Had we adopted such a method to force HTTP/2's on-wire compatibility with HTTP/1 by deciding how current H1 implementations must behave, we'd have had less difficulties to build a handshake. Eg: "deployed implementations must suddenly not do this nor that and it magically works". There's no way existing implementations will change their deployed working code just to take in consideration something they're not interested in, so I don't know what the end result will be when non-compliant implementations face compliant ones. Definitely strange form of alternate history :-/ Regards, Willy
Received on Thursday, 26 November 2015 06:54:37 UTC