Why do we set ContentLength even for GET and DELETE requests?

[per.lu...@ecraft.com]

Hi there,

Found out an interesting semantic detail with RestSharp the other day. It seems like RestSharp sets the Content-Length unconditionally, in the Http.Sync.cs file, in the ConfigureWebRequest method:

// make sure Content-Length header is always sent since default is -1

if(!HasFiles)

{

    webRequest.ContentLength = 0;

}

*However*, in the WriteRequestBody (also in Http.Sync.cs), we set the Content-Length based on the actual length of the body.

I feel this is not really a correct interpretation of the HTTP 1.1 spec (RFC2616), quoting section 14: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Applications SHOULD use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in section 4.4.

Any Content-Length greater than or equal to zero is a valid value. Section 4.4 describes how to determine the length of a message-body if a Content-Length is not given.

As can be seen in the quote, a zero content length is not valid anyway, so why set it to that in the first place? :)

This question arose because we where thinking about how to distinguish between HTTP DELETE requests with and without body. (RestSharp sends DELETE without a body, but with Content-Length set to zero, whereas other clients like jQuery.ajax() sends DELETE with a body.)

My suggestion, based on my current understanding is that we should drop the quoted part of the code unless there's a really compelling reason to have it like that in the first place.

Best regards,
Per

[per.lu...@ecraft.com]

Doh... I should be reading things more carefully. "Greater than OR EQUAL TO zero" quite obviously means that Content-Length: 0 is valid. :-)

Nonetheless - why set it at all if we don't provide a body? It's not a must based on the RFC afaik, so it would be really interesting to hear the rationale behind it.

Best regards,

Per