request.host_port is a str not an int

[dstufft]

This fixes a logic error in #2501 where I accidentally treated request.host_port as an int when in reality it is a str. This wasn't exposed in my own testing because I was only using non-standard ports so I expected this to evaluate to False anyways.

[dstufft]

Note, this essentially means the new automatic CSRF checking is broken on any site that uses standard ports right now.

[mmerickel]

Wow.. request.server_port is documented to an int and request.host_port is a string. What?

[dstufft]

Yea, I don't know :(

[sontek]

Rather than having the list be strings could you cast host_port to an int and use that? It would make sure if host_port ever got changed to an int that the code would continue to work.

if int(request.host_port) not in {80, 443}:

[dstufft]

I could do that. The reason I didn't was that I wasn't sure if it'd ever be possible for it to be something that isn't a valid int (empty string?).

Sent from my iPhone

On Apr 17, 2016, at 2:08 PM, John Anderson notifications@github.com wrote:

Rather than having the list be strings could you cast host_port to an int and use that? It would make sure if host_port ever got changed to an int that the code would continue to work.

if int(request.host_port) not in {80, 443}:
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

[digitalresistor]

Wondering if this is something to be fixed in WebOb...

[mmerickel]

I doubt you can just switch the type without causing people unnecessary pain. It'd be nice to know if there's a reason it's a string though.

[digitalresistor]

It's pulled from HTTP_HOST header, by slicing and dicing the string:

http://docs.webob.org/en/stable/api/request.html#webob.request.BaseRequest.host_port

I don't know if there is a reason for it being string over not.

[mmerickel]

On topic, I'm planning to merge this PR. Just bundling it together with a larger change that hopefully I can make later tonight.