#123 closed defect (fixed)

"text/plain" link uses double filename= query arg

Reported by: warner Owned by: warner
Priority: major Milestone: eventually
Component: code-frontend-web Version: 0.6.1
Keywords: Cc:
Launchpad Bug:


the web server provides a "text/plain" link on each file, to serve the data with the Content-Type forced to be text/plain . This is a convenience feature, to let users view a file which they know is just plain text, but which an overzealous server or browser thinks is something exotic: usually this impacts files with extensions like .py and .diff .

This feature is implemented by providing the usual href plus a "?filename=foo.txt", to force the content-type-choosing mechanism to use text/plain.

However, with the recent XSS/XSRF defenses, this link winds up with a double ?filename= queryarg. This probably still works, but it isn't valid HTML (two '?' characters in one URL), and is weird (two copies of the same argument).

This needs to be changed so that any existing filename= argument is replaced. There is probably a clever URLPath-based URL manipulation class available to do this sort of thing, particularly in Nevow.

Change History (8)

comment:1 Changed at 2007-08-23T23:09:38Z by warner

also, it might be a good idea to add a different query-argument here, maybe content-type= , and have an explicit content-type= argument override the decision made by looking at the filename.

This might allow download-link operations to work better, for when the user wants to save the file they're currently looking at.

comment:2 Changed at 2007-09-19T23:03:00Z by zooko

  • Milestone changed from 0.6.0 to 0.7.0

comment:3 Changed at 2007-09-28T02:39:13Z by warner

And actually, to make the download link work best, I think we might need to move to the approach we use on webfront, where the URL looks like http://$BASE/URI/$URI/filename.txt. This causes web browsers and other download tools (like wget and curl) to offer 'filename.txt' as the default target filename. It also makes it marginally more likely that the content-type will be derived from "filename.txt" instead of something else.

Without this, download the file tends to put it in $URI or $URI?stuff, which is really ugly.

comment:4 Changed at 2007-09-28T02:39:18Z by warner

  • Status changed from new to assigned

comment:5 Changed at 2007-11-01T18:14:07Z by zooko

  • Milestone changed from 0.7.0 to 0.7.1
  • Version changed from 0.5.1 to 0.6.1

We're focussing on an imminent v0.7.0 (see the roadmap) which hopefully has #197 -- Small Distributed Mutable Files and also a fix for #199 -- bad SHA-256. So I'm bumping less urgent tickets to v0.7.1.

comment:6 Changed at 2008-01-23T02:30:10Z by zooko

See also #221 and #277

comment:7 Changed at 2008-01-23T02:30:36Z by zooko

  • Milestone changed from 0.7.1 to undecided

comment:8 Changed at 2009-12-13T06:16:31Z by davidsarah

  • Resolution set to fixed
  • Status changed from assigned to closed

The current "Raw data as text/plain" link uses @@named=/raw.txt, which is not duplicated.

Note that if this feature is intended to defeat browser sniffing, it doesn't succeed in doing that -- for example see


which is displayed as an image (tested in Chrome). See #827 for how to defeat browser sniffing. However, that's a separate issue, so closing this ticket.

Note: See TracTickets for help on using tickets.