Issue #527 resolved

request.browser_url does not contain url fragments

Anonymous created an issue

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.

Reported by mikerobi

Comments (6)

  1. Robert Brewer

    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.

  2. Robert Brewer

    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?

  3. Anonymous

    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.

  4. Log in to comment