Ticket

how?

if you're doing .txt, shouldn't you get a textual reply, even if it's not there? offering the add type seems to suggest you would give an html reply to a text request.

  --Ethan McCutchen.....Wed Feb 16 12:15:26 -0800 2011

A blank page is just confusing. If the name before the .txt refers to something that doesn't exist, my thought is to go wiki and offer to add it (as if they went to the URL without the .txt). Open to other possibilities.

Is there a standard RESTful way to reply to requests for resources that don't exist?

API concerns and human interface concerns may pull in different directions here, but I'm sure we'll find a way to harmonize.

  --John Abbe.....Wed Feb 16 13:03:19 -0800 2011

I think we probably need special format-specific behaviors for missing cards. If you set up something to call a text page, you need to get text, even if it's text that says you can add it by going to a given url or whatever. For css it could be a css comment that explains it's a broken page.

The standard response code is 404, which we can do for any of these. But it's also very standard that the url ending specifies the mime-type, regardless of the response code.

  --Ethan McCutchen.....Wed Feb 16 13:24:18 -0800 2011

Still seems odd. I may be willing to go with that for .txt and .css, and generally file endings that by default browsers show directly (I wrote up how I imagine it working above). For things that the browser will normally download (.doc, .pdf, .rtf) I'd more strongly suggest we go non-standard. Giving people the experience of downloading a file, opening it, and having it direct them to a URL seems truly perverse.

  --John Abbe.....Wed Feb 16 13:56:03 -0800 2011

Now wondering if it shouldn't be a redirect to an html page (which offers to add it).