Subject: [mile] HTTP status codes in RFC 6546

From: <[email-masked]>
Date: Tue, 5 Jun 2012 12:41:33 -0400

All,

At the bottom of Page 2 and continuing to the top of Page 3, paragraph 1, the RFC states that:

"As RID messages MUST be sent using the POST method, the GET and HEAD methods have no particular meaning on a RID system; a RID system SHOULD answer 'GET /' or 'HEAD /' with 204 No Content."

Consistent with the HTTP RFC 2616 section 10.4.6, I would expect that the correct HTTP status code for a GET,  or HEAD request (or even a PUT or DELETE)  should be an HTTP 405 Method Not Allowed.  This would seem to be more correct, and also more helpful, since HTTP specifies that in this case the response headers would then include an Allow header that informs the client of the HTTP methods that may be used (in this case POST).

Is there some other constraint that motivated the choice of specifying a 204 status code?

Regards,
John

// John P. Field
// Security Architect
// EMC Office of the CTO
// mailto: [email-masked]
// http://www.emc.com

---

From: "Davidson II, Mark S" <[email-masked]>
Date: Wed, 6 Jun 2012 18:23:59 +0000

I did not write the RFC so I cannot speak to the motivation for those status codes.

I will say that I have the same question. Breaking RFC guidance may allow for more useful response codes / response messages. One limitation of the HTTP 204 response is that there is no message body, just message headers. With an HTTP 405 response you are allowed to include a response body.

-Mark

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, June 05, 2012 12:42 PM
To: [email-masked]
Subject: [mile] HTTP status codes in RFC 6546

All,

Regards,
John

// John P. Field
// Security Architect
// EMC Office of the CTO
// mailto: [email-masked]<mailto:[email-masked]>
// http://www.emc.com

---

From: <[email-masked]>
Date: Wed, 6 Jun 2012 16:40:36 -0400

Thank you, John and Mark!

I believe Brian is traveling, so if others have opinions and want to weigh in on the two identified issues/questions, that may be helpful.  If we work through this and find there is an issue to correct (and there seems to be), as John suggested, he can file an errata report and Brian can include the agreed upon solution in the errata report.  The errata report would update the RFC, hence maintaining compliance with the updated RFC.

Thank you,
Kathleen

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Davidson II, Mark S [[email-masked]]
Sent: Wednesday, June 06, 2012 2:23 PM
To: Field, John; [email-masked]
Subject: Re: [mile] HTTP status codes in RFC 6546

-Mark

All,

“As RID messages MUST be sent using the POST method, the GET and HEAD methods have no particular meaning on a RID system; a RID system SHOULD answer 'GET /' or 'HEAD /' with 204 No Content.”

Regards,
John

// John P. Field
// Security Architect
// EMC Office of the CTO

---

From: Michael Hammer <[email-masked]>
Date: Thu, 7 Jun 2012 13:35:25 +0000

Correct me if I am wrong, but a 200 series code usually means success.
300 series a redirection, and 400, 500, 600 series means failure.

So why a 204 response for what seems to be a failure?

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, June 06, 2012 4:41 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mile] HTTP status codes in RFC 6546

I believe Brian is traveling, so if others have opinions and want to weigh
in on the two identified issues/questions, that may be helpful.  If we work
through this and find there is an issue to correct (and there seems to be),
as John suggested, he can file an errata report and Brian can include the
agreed upon solution in the errata report.  The errata report would update
the RFC, hence maintaining compliance with the updated RFC.

Thank you,
Kathleen

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Davidson
II, Mark S [[email-masked]]
Sent: Wednesday, June 06, 2012 2:23 PM
To: Field, John; [email-masked]
Subject: Re: [mile] HTTP status codes in RFC 6546

I did not write the RFC so I cannot speak to the motivation for those status
codes.

I will say that I have the same question. Breaking RFC guidance may allow
for more useful response codes / response messages. One limitation of the
HTTP 204 response is that there is no message body, just message headers.
With an HTTP 405 response you are allowed to include a response body.

-Mark

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, June 05, 2012 12:42 PM
To: [email-masked]
Subject: [mile] HTTP status codes in RFC 6546

All,

At the bottom of Page 2 and continuing to the top of Page 3, paragraph 1,
the RFC states that:

"As RID messages MUST be sent using the POST method, the GET and HEAD
methods have no particular meaning on a RID system; a RID system SHOULD
answer 'GET /' or 'HEAD /' with 204 No Content."

Consistent with the HTTP RFC 2616 section 10.4.6, I would expect that the
correct HTTP status code for a GET,  or HEAD request (or even a PUT or
DELETE)  should be an HTTP 405 Method Not Allowed.  This would seem to be
more correct, and also more helpful, since HTTP specifies that in this case
the response headers would then include an Allow header that informs the
client of the HTTP methods that may be used (in this case POST).

Is there some other constraint that motivated the choice of specifying a 204
status code?

Regards,
John

// John P. Field
// Security Architect
// EMC Office of the CTO

_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile

---

From: Brian Trammell <[email-masked]>
Date: Tue, 12 Jun 2012 09:08:00 +0200

Greetings, all,

Replying as author of RFC 6546.

The intent is that RID over HTTPS should be relatively quickly and simply implementable atop existing HTTPS server infrastructure. As a RID server cannot meaningfully generate content for a GET or a HEAD, 204 No Content seemed (1) appropriate and (2) simple to implement. I chose 204 during the appsdir review as my reading of 2616 at the time seemed to indicate that 405 wasn't allowed for the root, but on rereading I'm not sure where I got this idea.

Selecting a return code for GET / or HEAD / is a bit of a corner case: the exchange not one that is normally encountered in RID, as RID systems exchanging messages with each other will never use these methods. Non-RID System clients should never see an HTTP response to GET / or HEAD /, as they would fail TLS negotiation first -- accidental or curious clients should in no case have a valid certificate to connect to a RID system (see paragraphs 13-18 in section 3 of RFC 6546, and section 9.3 of RFC 6545).

However, a more correct response would indeed be 405, so it probably makes sense to file a technical erratum on the RFC.

Best regards,

Brian

---

From: <[email-masked]>
Date: Mon, 25 Jun 2012 10:40:44 -0400

Brian,

Thanks for your reply.  I'll work with Kathleen to file the required errata.

Regards,
John

-----Original Message-----
From: Brian Trammell [mailto:[email-masked]] 
Sent: Tuesday, June 12, 2012 3:08 AM
To: <[email-masked]>
Cc: Moriarty, Kathleen; [email-masked]; Field, John; Michael Hammer
Subject: Re: [mile] HTTP status codes in RFC 6546

Greetings, all,

Best regards,

Brian