ietf-nntp 502 response

Andrew Gierth andrew at erlenstar.demon.co.uk
Thu Jan 3 04:09:26 PST 2002


>>>>> "Clive" == Clive D W Feather <clive at demon.net> writes:

 Clive> Hmm, I see that 502 is also used by some commands to mean
 Clive> "something broke".

 >> I suspect that all such occurrences are erroneous.

 Clive> They've been there for a while. Do they need to be removed ?

I need to review the latest draft.

 Clive> Under what circumstances do real servers return 502 ?
 
 >> on connect, or after a failed AUTHINFO exchange, nowhere else.

 Clive> It's given as a response for MODE READER

actually that one is in line with existing practice; with INN, if you
have transfer access but no reader access, then a "MODE READER" command
will respond with 502 (and then close the connection).

 Clive> and as a generic code meaning "you're not authorised to use
 Clive> this facility" (a possible example of this might be GROUP with
 Clive> a restricted-access group).

This one is very marginal. Existing practice is to respond "no such
group" if the user does not have access to the group. This means that
the client can't distinguish between nonexistent and inaccessible
groups. However, another option would be to respond with 480 (which of
course we don't define) meaning "authentication required".

I don't like the current description of 502 because if permission for
something is denied, normally one would expect that only
authentication would change that condition, implying that the response
should have been 480 in the first place.

I think we need to include 480 in this document even though we can't
incorporate the rest of the authentication stuff, because otherwise
authentication would break the "server MUST NOT produce any other
responses to a client that does not invoke any of the additional
features" rule.

 Clive> Does anyone have a server that uses 502 for "something broke" ?

 Clive> Do we need a "something broke" generic code ?

that's what 503 is used for in existing practice

-- 
Andrew.



More information about the ietf-nntp mailing list