ws_location does not contain query on some setups

[GoogleCodeExporter]

What steps will reproduce the problem?

On Tue, 19 Oct 2010 22:05:35 +0200, Joe Mason <jmas..@rim.com> 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  
> http://modpython.org/live/current/doc-html/pyapi-mprequest-mem.html).   
> And the source for mod_pywebsocket (file handshake/_base.py) 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 code.google.com by zcor...@gmail.com on 20 Oct 2010 at 1:57

[GoogleCodeExporter]

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

Original comment by googlere...@notcharles.ca on 27 Oct 2010 at 4:13

[GoogleCodeExporter]

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

Original comment by jma...@rim.com on 27 Oct 2010 at 4:18

[GoogleCodeExporter]

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 
location.

Original comment by zcor...@gmail.com on 28 Oct 2010 at 7:25

[GoogleCodeExporter]

The HyBi 07 protocol, the latest spec as of this writing, doesn't use 
Sec-WebSocket-Location
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07

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

Original comment by yuzo@chromium.org on 25 Apr 2011 at 11:34

• Changed state: WontFix

[GoogleCodeExporter]

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 
http://modpython.org/live/current/doc-html/pyapi-mprequest-mem.html

Original comment by zcor...@gmail.com on 7 Mar 2013 at 12:51

[GoogleCodeExporter]

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 
Request-Line.
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 tyoshino@chromium.org on 13 Mar 2013 at 5:14

• Changed state: Started

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Fixed location header generation.
https://code.google.com/p/pywebsocket/source/detail?r=741

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 tyoshino@chromium.org on 9 Apr 2013 at 11:28

• Changed state: Fixed