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

[Tim Delaney]

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
redirecting.

For other filtered changesets that are not covered by another case, I
prefer 403 (it exists, but you're not allowed to see it).

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