Ticket #527 (defect)
Opened 3 years ago
Last modified 2 years ago
request.browser_url does not contain url fragments
Status: closed (fixed)
| Reported by: | mikerobi | Assigned to: | mikerobi |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | CherryPy code | Keywords: | browser_url, fragment |
| Cc: |
Most good web clients strip uri fragments from the request, so they are of no use for web applications. The presence of a uri fragment is an indication of a problem with the client. While most applications can quietly ignore the fragment, but for some applications a fragment should result in an invalid request.
For example:
A webdav client should never issue a request “DELETE http://foo.com/resouce#bar”, the meaning of the fragment is undefined, so the server should not delete the resource, and respond with a “400 bad request.”
Currently the browser_url is constructed from the components returned by httptools.parse_request, we could simply return the fragment string with the rest of the uri components. It may be better for parse_request, to return the entire unparsed request URI (along with the components). This might be useful if an application cares if the host name in the URI differs from the host in the request header.
Change History
05/30/06 16:02:50: Modified by fumanchu
05/30/06 16:46:25: Modified by fumanchu
Lawouach felt Yet Another Config Entry might be overkill, and I agree. Can we return the fragment from httplib.parse_request_line, and stuff it into a new request.fragment attribute?
05/30/06 19:04:12: Modified by mikerobi
I was not trying to suggest that we have an option for CP to produce an error, I just need access to the fragment so my application can decide what to do.
I think that browser_url should be true to its name and contain whatever url the browser requests. It would be misleading to use it to store anything else.
I would be suprised if adding the fragment to browser_url would breaks anything. Neither Firefox, Opera, Konqueror, Links, w3m, wget, or IE, submit fragments with requests. The curl console app and snarf are the only clients I found that submit fragments. That being said, I must admit the chance that this may be a problem for some really obscure browsers and spambots.
08/12/06 02:51:18: Modified by fumanchu
Fragments are not allowed in the Request-URI per the spec. Given that the only mention of IE incorrectly sending fragments is a bug report from 2003, perhaps we could start issuing 400 if a fragment is included. If that resolution works, it seems infinitely better to me than passing the fragment up the stack via a custom WSGI environ entry (when using the default server).
09/02/06 03:51:53: Modified by fumanchu
- status changed from new to closed.
- resolution set to fixed.
Fixed in [1314]. The builtin WSGI server now returns "400 Bad Request".
Hmmm. I understand the need but am not convinced that browser_url is the right place to address it (it would certainly make trailing-slash-redirects harder, for example). Are there any behaviors we want to support other than ignore or error? If not, I'd rather vote for a "error_on_uri_fragment" config entry or something similar.