Is <content> required on a POST?

[Sam Ruby <rubys@xxxxxxxxxxxxxxxx>]

Background: I am starting to look at building up test suites for both 
clients and servers.  The goal is to maximize interoperability by making 
as much as possible predictable.

Lets start small.  After the first few elements, the rest should go faster.

The atom:content [1] element is defined to have a mandatory type 
attribute, and an optional mode attribute.  Multipart/alternative, 
xml:base, xml:lang may affect how this is to be interpreted.  There are 
invalid values to be tested for many of these attributes - either 
because they are out of spec, or because a given server implementation 
may not support a given combination (example: is it OK for a wiki to 
reject a POST of a jpeg?).

But lets start even more basic than that.  Content elements are not 
required when syndicating, but should this element be required on a 
POST?  If content is required, but is absent, should we specify how the 
server is to react?

Enough questions, now lets start the discussion with a proposal.  Lets 
make content required on a POST.  By this I mean that if the content 
element is not present, the request is invalid and must be rejected by 
the server.  If *ONLY* thing wrong with the request is that the content 
is missing, then the server MUST respond with a status code [2] of "Bad 
request 400".  Furthermore, somewhere in the body of the response must 
be the string "content".

The way this would be tested for is simple.  First we need to define a 
simple "hello world" post that all servers MUST accept (that sounds 
deceptively simple, I suspect it won't be).  And then we vary that 
request by omitting the content, issuing the request, and examining the 
response.

As I indicated above, the result of this discussion is likely to set a 
bunch of precedents for how other conditions are to be handled.  By 
requiring the server to check for a number of specific conditions, we 
are increasing consistency in both client and server implementations and 
therefore increasing interoperability; however this potentially comes at 
the expense of server implementation costs and flexibility.

This is a balance.  As an example, while I don't believe that any server 
should be required to accept requests that are not well formed XML, I 
also don't believe that having a fully validating XML parser should be a 
requirement for implementing Atom.

Clearly, I am making a number of assumptions.  Lets get them out on the 
table and examine them.  Here's the ones that I am aware of:

1) I am presuming that checking for a missing element does not require 
much more than an an "if" check on the server.

2) The content element is important enough to warrant such a check.

3) The existence of a standalone test suite that implementors can use to 
self-test is sufficient to make voluntary compliance with requirements 
such as these easy enough to achieve.

There.  That should be enough to start a discussion.  Before wandering 
off into other elements and attributes, let's settle this one question 
first: is <content> required on a POST?

- Sam Ruby

[1] 
http://www.mnot.net/drafts/draft-nottingham-atom-format-00.html#rfc.section.3.2.10
[2] http://www.w3.org/Protocols/HTTP/HTRESP.html