Ben Kallus

We also accept `urlparse("http://python.org:\r\n80\r\n").port`, because `int` trims whitespace. I think it's plausible that there are security concerns stemming from desyncing a front-end server using urlparse from a backend server using...

> I just ran into this issue with whitespace. It didn't cause a security issue, but rather a bunch of unexpected errors: > > ``` > >>> urlparse(' https://example.com ')...

> Hmmm... interesting, what about the case without a scheme with port? > > ``` > >>> urlparse('www.example.com:80') > ParseResult(scheme='www.example.com', netloc='', path='80', params='', query='', fragment='') > ``` This is just...

@JelleZijlstra I think it makes way more sense to move port validation entirely to parse time, a la #25774, so it might not make sense to implement these fixes until...

> There's another case to consider: Unicode digits! For example, your patch still allows a port of `६`, which is the Devanagari character for 6. Your quote from the RFC...

Using urllib3 may not be ideal because that project officially supports only HTTP URLs. This can cause problems with other schemes. For example, when parsing a `tel` URL with urllib3,...

Yes, this was tested on the latest master. Any proxy that doesn't normalize LF into CRLF as a header line terminator would work. This is a pretty easy mistake to...

> I don't see in the current example how an application could be in atatcked unless it's using an header like this. We protect already against long lines. I'll give...

This attack has always been possible. The new RFCs require implementations to protect against it, and the older ones didn't. The new RFCs don't introduce this issue; they address it....

> Can you give a more concrete example of how you're using relative paths with urllib3? Sure. If you were trying to parse a `tel` URL, like `tel:1-603-646-1110`. urllib3 does...