Display a consistent response body for URIs with no mementos

[machawk1]

The current deployment (1.0-rc2) has a response body of "404 not found", which is inconsistent with the sort of response that comes with a non-404, namely, the URI-R used in the query is returned within an "original URI" field. Having a TM at the endpoint when a 404 occurs with metadata using Memento semantics, even if no mementos are contained within, would be useful.

My particular use case is with Mink changing the URI for submission to the archives in this case.

If nothing else, I would be interested in your thoughts on the above behavior, @ibnesayeed .

[ibnesayeed]

I understand that having the response in the same (requested) format is helpful despite the success or failure status of the response. However, it encourages to define and promise the response body format even in case of failure. Usually the data in failed responses is only for informational purposes (suggestive nature) that the application should generally not be relied upon. In client applications it is advised to check for failure via the status code and take necessary steps without relying the content of the response. In contrast, I do know some Web API services that implement throttling and return a structured data to help clients take necessary steps in case of failure due to posed limits (such as you have reached max requests per hour and should wait until T1), but this is only necessary when the information in the response is not known by the client otherwise.

[ibnesayeed]

LANL server gives a 404 response body (of "We Do It" TimeMap) with content-type text/plain that looks like this:

 not found for url: {URI-R}

[scott-ainsworth]

When the Wayback Machine returns 404, it means not archived. Should 404 have the same meaning as in a multi-archive environment? I think so. So, if all archives return 404 (or some other not archived indication), then memgator should also return a 404. This way 404 means "not archived" for both single- and multi-archive scenarios.

[ibnesayeed]

@galsondor, MemGator does return 404. However this ticket is about the payload which is text/plain for now. @machawk1 was asking for the failed response to be returned using the same media type as the OK response (JSON/Link or something else as requested by the client). Please read my comment above to understand the situation. Here is how the current failed response looks irrespective of the format requested by the client:

HTTP/1.1 404 Not Found
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Link, Location, X-Memento-Count, X-Generator
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
X-Generator: MemGator:1.0-rc3
X-Memento-Count: 0
Date: Tue, 10 Nov 2015 03:15:39 GMT
Content-Length: 19

404 page not found

[scott-ainsworth]

Got it. I think I agree with @machawk1. Unfortunately, the RFC is silent on this. My only concern is that returning a timemap does not necessarily leave room for other useful information.

[ibnesayeed]

As I said there are good use cases if the failed response is also in the desired format requested by the client, but there are two issues:

• The structure of the failure response needs to be documented and maintained for every supported format.
• Not every format allows the degree of expressiveness needed to convey the message.

On the other hand, payload in failed responses is usually only for informational purposes and not intended to be relied upon for a client application to work properly.

[ibnesayeed]

I think this can be closed, but if we ever come up with a unified means of error reporting then we can consider it again.