Re: gnatsd output question

["Mark D. Baushke" <mdb@juniper.net>]

On Wed, 5 Sep 2001 09:54:17 +0100, "Marcus Williams" <marcus@quintic.co.uk>
wrote:
>
> [snip]
> 
> I'd tend to agree with Rick Macdonald that the lock messages are
> internal to Gnats so dont need to be displayed (unless they fail).

Agreed.

> It may be worth doing something like the FTP specs (RFC 0959?) say and
> wrap the three messages inside a multiline result so it becomes (from
> what I remember of the RFC):

Yes, it is RFC 959.

> subm
> 211 Ok.
> .
> 210- GNATS database is now locked
> 402- Failure reading header
> 210- GNATS database is now unlocked
> 
> The trailing dash after the result code indicates a multiline
> continuation. However, this is wrong as well as we're only interested
> in the 402 in the middle so it probably should be
> 
> subm
> 211 Ok.
> .
> 402- GNATS database is now locked
> 402- Failure reading header
> 402- GNATS database is now unlocked
> 
> Since you can only tell that theres a header error by reading the full
> message, maybe more error codes should be added so then we can
> exchange 402 for whatever the code is for "Failure reading header".
> The multiline reply is then only for interactive/information purposes.
> 
> Marcus

Well, that is not really what RFC 959 says.

|      A reply is defined to contain the 3-digit code, followed by Space
|
|
|Postel & Reynolds                                              [Page 35]
|
|
|                                                                        
|RFC 959                                                     October 1985
|File Transfer Protocol
|
|
|      <SP>, followed by one line of text (where some maximum line length
|      has been specified), and terminated by the Telnet end-of-line
|      code.  There will be cases however, where the text is longer than
|      a single line.  In these cases the complete text must be bracketed
|      so the User-process knows when it may stop reading the reply (i.e.
|      stop processing input on the control connection) and go do other
|      things.  This requires a special format on the first line to
|      indicate that more than one line is coming, and another on the
|      last line to designate it as the last.  At least one of these must
|      contain the appropriate reply code to indicate the state of the
|      transaction.  To satisfy all factions, it was decided that both
|      the first and last line codes should be the same.
|
|         Thus the format for multi-line replies is that the first line
|         will begin with the exact required reply code, followed
|         immediately by a Hyphen, "-" (also known as Minus), followed by
|         text.  The last line will begin with the same code, followed
|         immediately by Space <SP>, optionally some text, and the Telnet
|         end-of-line code.
|
|            For example:
|                                123-First line
|                                Second line
|                                  234 A line beginning with numbers
|                                123 The last line
|
|         The user-process then simply needs to search for the second
|         occurrence of the same reply code, followed by <SP> (Space), at
|         the beginning of a line, and ignore all intermediary lines.  If
|         an intermediary line begins with a 3-digit number, the Server
|         must pad the front  to avoid confusion.

So, if you want to use this style of semantics, the error number must
be the same for the first and last lines of the response. The last
line of the response MUST NOT contain a '-' after the number.

In practice, most servers use the same number- as a prefix for the
message:

	123-First line
	123-Second line
	123-234 a line beginning with numbers
	123 The last line

So, even if this method were to be adopted, it should probably NOT be
generating more than one return number as for the database lock and
unlock steps.

	Enjoy!
	-- Mark