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

Tim Delaney timothy.c.delaney at gmail.com
Sat Aug 17 22:18:34 CDT 2013


On 16 August 2013 09:57, Pierre-Yves David
<pierre-yves.david at ens-lyon.org>wrote:

>
> On 8 août 2013, at 09:48, Dan Villiom Podlaski Christiansen wrote:
>
> > # HG changeset patch
> > # User Dan Villiom Podlaski Christiansen  <danchr at gmail.com>
> > # Date 1375624663 -7200
> > #      Sun Aug 04 15:57:43 2013 +0200
> > # Node ID 5507e2af80f5e8026a054ce440c0c8958134eefe
> > # Parent  b1f7ae28c3e371a70ee363a4fbe5d50063a224fc
> > hgweb: handle obsolete changesets gracefully
> >
> > If the changeset has any successors, issue a 403 Moved Permanently;
> > otherwise we issue a 410 Gone. Please note that this is slightly
> > misleading for 'secret' changesets, as they may appear later on.
>
> You are going too fast here.
>
> 1) issue 410 for filtered changeset
> 1.1) (403 or 404 for secret ?)
> 2) issue a smarter message with potential link to successors (could
> include information about who and when it was rewritten)
> 3) use redirect (does not like the idea yet)


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.

Tim Delaney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130818/577ad064/attachment.html>


More information about the Mercurial-devel mailing list