On 6/9/2017 1:26 PM, Warren Young wrote:
On Jun 9, 2017, at 7:11 AM, Richard Hipp <d...@sqlite.org> wrote:
Perhaps /tarball and /zip are special in the sense that they are often
accessed by scripts.
I don’t have any data on whether that is true, but you are right that /webpages
frequently accessed by scripts should return sensible HTTP result codes.
/webpages exclusively accessed from a browser can return 200 in all cases,
since the only way to see the error code is to drop into the browser’s
developer tools. If the error report is inline in the HTML, 200 is even
arguably correct.
A 404 page is almost always valid HTML, and often cleverly styled. Most
browsers will show it and other status pages to the end user. But you
are right that they won't show the actual HTTP status, the end user is
trusting that the error page is presenting sensible information.
I suppose you could argue that /zip (and /tarball) should not present
text, ever. But in their normal usage by scripts, the returned content
would be completely ignored unless status was 200.
The JSON API should be scrupulous about returning correct HTTP result codes.
The JSON API returns 200 for any result that can be best explained by a
JSON result record, which itself contains a status. This is consistent
with treating HTTP as the transport protocol. The HTTP transaction
worked, so 200 is the correct response code, even if a parameter made
the /json API endpoint not take the intended action.
A code other than 200 would be correct if /json were not a valid URL at
all, or if some other hard failure occurred. Other than JSON not
compiled in, there aren't supposed to be very many cases where the JSON
engine can't describe the situation for itself.
Look at it this way. If access to /json/nosuchapi returns HTTP status
200, then the caller can expect to have a JSON document to parse. If it
doesn't, then it can't expect the result contains anything parseable at
all, and in general the content of a 404 page is human readable text.
Given that the /json namespace is intended for use by automation that
wants to consume JSON, attempting to guarantee that any access within
that namespace will be HTTP 200 with a JSON packet explaining the API
call results seems reasonable.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
