Comment 8 for bug 605775

On 8 December 2010 02:32, Max Kanat-Alexander <email address hidden> wrote:
> Okay, that all makes sense, except that not all of the content in the
> VCS is text (although of course most of it is). When I ask for the raw
> content of a png, I as a user expect to actually view a png image in my
> browser. I wouldn't expect to have to go to some separate URL for that.

That's true.

I guess really there are two(?) types of URL: download, and view. You
should always be able to download and it should always give you c-d:
attachment; and in some cases you can view it inline.

What happens on the 'view it inline' case is going to depend on the
site configuration:

1- Don't worry about xss and are happy to just show whatever's in the
branch; too easy
2- Configure one or more separate download domains and let it be
pulled from there
3- Show content that's known to be safe. I think that in practice
determining what counts as "safe" is going to be a bit tricky, it
seems to me, because it needs to work around browser content sniffing,
but we can probably do it.
3a - Defang the content, by eg turning text into escaped html.

> I suppose I could call the controllers /text/ and /content/ or
> something, but how would I even differentiate those in the UI? That
> would be confusing for the user. Also, I'd have to put a /text/ link on
> the inventory view (the /files browser) for every file in the inventory,
> because I can't reliably check the MIME type of every file when I'm
> displaying the contents of the inventory. So there would be /text/ links
> for binary files, which wouldn't make sense at all.

I agree we don't want to check the type until the user actually asks
for it, so actually /text/ is a bad idea, as is enabling this only on
files that are safe to download.

--
Martin