[PATCH 3 of 3 RFC] hgweb: handle obsolete changesets gracefully

Pierre-Yves David pierre-yves.david at ens-lyon.org
Tue Sep 3 13:00:27 CDT 2013


On 18 août 2013, at 05:18, Tim Delaney wrote:

> IMO 410 Gone should not be used for filtered changesets - 410 should be considered to be a permanent condition. The only case I think a 410 would be appropriate would be an obsolete changeset with no successors (this situation could change, but that would be unusual).
> 
> If an obsolete changeset has multiple successors then I think 409 Conflict would be appropriate since it is possible for the user to resolve the conflict and resubmit.
> 
> For all other filtered changesets I think 403 or 404 is the most appropriate response. 403 feels more appropriate to me, but does leak some information about the filtered changeset that wouldn't be leaked by a 404. OTOH I personally think that it would be useful to distinguish between a filtered changeset and a non-existent changeset, so would favour 403.

=== Core reply ===

I think you under-estimate the complexity of situation we can get. My point in the previous email was: "We need to get a better status and error message when stuff are filtered. When we have a better status/error we can think about special handling of situation".

It could be anything that fit generic filtering right. We could use 418 but you seems right, 403 request seem the way to go in that case (RFC content below for the record)
(special handling of secret may exist)

> 403 - FORBIDDEN: The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

(note: I'm not so happy to use 'FORBIDDEN' for obsolete changeset as there is no reason for not giving an ultimate way to retrieve them.)

=== Complexity example ===

Here is example of sightly different situation. I'm not telling that it's impossible to take the right decision for all of them. I'm pointing that we can't expect to embrace everything in one go.

Should the treat the same way:

- changeset obsolete with no successors ?
- changeset obsolete with an unknown successors ?
- changeset obsolete with a known secret successors ?

(read successors as: successors set in all sentences above)

Should the treat the same way:
- changeset have two possible successors set (diverse)
- changeset have a single successors set with two consecutive changesets (split)
- changeset have a single successors set with two changesets on different head (split + move)

-- 
Pierre-Yves






More information about the Mercurial-devel mailing list