Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#109 closed defect (wontfix)

nnrpd doesn't return 420 errors for XOVER

Reported by: Julien ÉLIE Owned by: eagle
Priority: low Milestone:
Component: nnrpd Version:
Severity: normal Keywords: compliance
Cc:

Description

According to RFC 2980, section 2.8:

If no articles are in the range specified, a 420 error response is returned by the server.

nnrpd (from the beginning of the XOVER command) has always returned a 224 response with an empty multiline response instead.

Note that the OVER command properly returns 423 (no articles in that range) when that case occurs. 420 is sent when the current article number is invalid.

Impact: Less information is communicated to the client about why there are no overview records returned. An error response indicating there are no valid articles in that range is possibly more informative.

There is probably no way to fix this now. Changing the reply codes would break a few existing implementations: it may confuse some clients that don't expect to get 420 errors back from overview queries. Clients may be relying on the existing behavior (confirmed with Outlook Express/Windows? Mail for instance).

Change History (2)

comment:1 Changed 11 years ago by Julien ÉLIE

Resolution: wontfix
Status: newclosed

comment:2 Changed 11 years ago by Julien ÉLIE

Regarding XHDR, nnrpd does not use 420 either but RFC 2980 makes this behaviour acceptable:

Some implementations will return "(none)" followed by a period on a line by itself if no headers match in any of the articles searched.
Others return the 221 response code followed by a period on a line by itself.

Note: See TracTickets for help on using tickets.