Skip to content
This repository has been archived by the owner on Jun 9, 2020. It is now read-only.

ws_location does not contain query on some setups #68

GoogleCodeExporter opened this issue Aug 20, 2015 · 8 comments

ws_location does not contain query on some setups #68

GoogleCodeExporter opened this issue Aug 20, 2015 · 8 comments


Copy link

What steps will reproduce the problem?

On Tue, 19 Oct 2010 22:05:35 +0200, Joe Mason <> wrote:

> msgutil._write(request, urllib.unquote(request.ws_location.split('?',  
> 1)[1]).decode("string-escape"))
> At this point, I have:
> request.ws_location is ws://localhost:8007/open_then_sleep_2_raw
> request.unparsed_uri is /open_then_sleep_2_raw?%5Cx00test%5CxFF
> request.uri is /open_then_sleep_2_raw
> So it looks like the handler is expecting ws_location to contain the  
> query, but it's not.
> I'm using mod_python 3.3.1 and mod_pywebsocket svn r274.  The docs for  
> mod_python say that it's correct for uri to not contain the query  
> string: "uri - The path portion of the URI." (From  
> And the source for mod_pywebsocket (file handshake/ shows that  
> only request.uri is being added into ws_location, not the query:
> def build_location(request):
>     """Build WebSocket location for request."""
>     location_parts = []
>     if request.is_https():
>         location_parts.append(WEB_SOCKET_SECURE_SCHEME)
>     else:
>         location_parts.append(WEB_SOCKET_SCHEME)
>     location_parts.append('://')
>     host, port = parse_host_header(request)
>     connection_port = request.connection.local_addr[1]
>     if port != connection_port:
>         raise HandshakeError('Header/connection port mismatch: %d/%d' %
>                              (port, connection_port))
>     location_parts.append(host)
>     if (port != default_port(request.is_https())):
>         location_parts.append(':')
>         location_parts.append(str(port))
>     location_parts.append(request.uri)
>     return ''.join(location_parts)
> I assume this is failing for me because I'm using a different version of  
> mod_python and/or mod_pywebsocket than you are, and your ws_location is  
> including the uri.

What is the expected output? What do you see instead?
I expect ws_location to contain the query (it does in my setup), but for Joe 
Mason it did not contain the query.

What version of the product are you using? On what operating system?

Please provide any additional information below.

Original issue reported on by on 20 Oct 2010 at 1:57

Copy link

Another data point is that I am using Windows, while I believe zcorpan is using 

Original comment by on 27 Oct 2010 at 4:13

Copy link

That last comment was by me - was signed in with the wrong account.

Original comment by on 27 Oct 2010 at 4:18

Copy link

This bug also causes the connection to be refused by conforming clients if a 
query is used, since Sec-WebSocket-Location doesn't match the requested 

Original comment by on 28 Oct 2010 at 7:25

Copy link

The HyBi 07 protocol, the latest spec as of this writing, doesn't use 

So there is not much point fixing this now. Sorry.

Original comment by on 25 Apr 2011 at 11:34

  • Changed state: WontFix

Copy link

Please reopen.

That Sec-WebSocket-Location was removed does not invalidate this bug. It is 
still useful to be able to read the query part of the URL.

I'm not sure why `uri` is different on different setups (bug in python's 
request members?), but maybe `parsed_uri[6]` more consistently gives the path. 
The query should be available from `parsed_uri[7]` or `args`, from my 
understanding of

Original comment by on 7 Mar 2013 at 12:51

Copy link

We used BaseHTTPRequestHandler.path value as-is to mimic mp_request.uri in 
_StandaloneRequest by mistake.

BaseHTTPRequestHandler.path holds the raw data at the Request-URI part of the 
mp_request.uri holds the path portion of the URI obtained by parsing the URI.

According to draft-ietf-hybi-thewebsocketprotocol-00 Section 5.1, we must use 
the full raw data,  though Section 3.1 of the I-D says /resource name/ is the 
<path> component obtained by parsing the URL following the Web address spec.

OK. I'll fix the location building method to use unparsed_uri

Original comment by on 13 Mar 2013 at 5:14

  • Changed state: Started

Copy link

[deleted comment]

Copy link

Fixed location header generation.

For now we leave the behavior of _StandaloneRequest.uri property not to break 
existing services. We've added _StandaloneRequest.unparsed_uri property that 
behaves the same as run with mod_python. So, now you can use unparsed_uri in 
both mod_python mode and standalone mode.

Original comment by on 9 Apr 2013 at 11:28

  • Changed state: Fixed

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet

No branches or pull requests

1 participant