3 ms·
I've been chugging away at a direct translation of RFC 2616 into parser/pretty-printer pairs in Haskell [1]. It's taken me a few times to get it right and I've
by tel 13y ago
I've been chugging away at a direct translation of RFC 2616 into parser/pretty-printer pairs in Haskell [1]. It's taken me a few times to get it right and I've learned a bit in the process such as RFC 2396 having an ambiguous grammar (look for 2 calls to `micro` in my code which penalize parsing to simulate a greedy algorithm). I cannot imagine almost any URL decoder/encoder 'in the wild' being actually RFC compliant.
There's also some difficulty with how RFC 2616 (the current HTTP/1.1 spec) demands using definitions of URLs from RFC 2396 which is not the current URI spec, but the update URI spec seemed to me to be inconsistent with general usage of HTTP. If I remember correctly, it ended up implying that you cannot have a query string without sending your scheme as well, but I may be wrong.
The URI spec is hideously complex, but also very comprehensively defined in those RFCs. It's an interesting job to look through them.
[1] https://github.com/tel/requests https://github.com/tel/requests
- pyre 13y ago| you cannot have a query string without sending | your scheme as well, but I may be wrong I don't remember reading that in the RFC. Also, I'm curious for examples of URLs that break RFC 3986[1]. [1] http://tools.ietf.org/html/rfc3986 http://tools.ietf.org/html/rfc3986
- tel 13y agoIt wasn't URLs that break RFC 3986, it was more an instance of Postel's Law where some common URLs people might send and parse in HTTP messages every day actually weren't allowed in HTTP according to the upgrade path from RFC 2396. When I became worried about that possibility I decided to jump back to 2396 since that's the RFC that 2616 truly inherits from.