[PATCH 3 of 3 RFC] hgweb: handle obsolete changesets gracefully
timothy.c.delaney at gmail.com
Tue Aug 20 17:29:42 CDT 2013
On 20 August 2013 19:53, Laurens Holst <laurens.nospam at grauw.nl> wrote:
> Op 18-08-13 05:18, Tim Delaney schreef:
> 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>
>> > If the changeset has any successors, issue a 403 Moved Permanently;
> The 403 status code is Forbidden.
> You mean 301 Moved Permanently?
This had been commented on previously - didn't see any need for me to ;)
> > 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.
> As long as it’s 404 when the changeset is in the secret phase.
> It must not be possible to identify whether a secret changeset with a
> certain hash exists.
Yes - a secret changeset should always return 404 no matter what other
states apply. That includes an obsolete changeset with a single secret
successor - asking for the obsolete changeset should return 404 instead of
For other filtered changesets that are not covered by another case, I
prefer 403 (it exists, but you're not allowed to see it).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mercurial-devel