Status of the HTTP Head verb in the Web API

Topics: ASP.NET Web API
Jun 20, 2012 at 11:57 PM

Hi,

I know that HEAD is not a common verb but since Web API is such an excellent implementation of HTTP spec, I would really love to see this working nicely. With rising adoption of REST/HTTP style APIs, it is very likely for more advanced clients to try HEAD before GET.

I think the problem lies in the fact that HEAD is a special verb in HTTP while its implementation in Web API is not: it has been implemented similar to the rest of the verbs. 

In fact, HttpHeadAttribute does not make much sense (neither an action called "Head") since HEAD is nothing but a content-less GET:

"The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request."

So HEAD is actually a special case GET. As such I would expect it to handled by the GET action, only the content is not sent back - no Head action or HttpHeadAttribute.

Is there any plan to implement this as such? I am more than happy to make a Pull Request but I would like to know the view of the team first.

Cheers

Ali

 

 

 

 

Jun 21, 2012 at 12:36 AM
Why would you want the GET method to handle that, possibly executing a fair amount of handling on the server side with no intention of ever returning the results of that processing? Sounds like a waste of resources to me.

On Wed, Jun 20, 2012 at 5:57 PM, aliostad <notifications@codeplex.com> wrote:

From: aliostad

Hi,

I know that HEAD is not a common verb but since Web API is such an excellent implementation of HTTP spec, I would really love to see this working nicely. With rising adoption of REST/HTTP style APIs, it is very likely for more advanced clients to try HEAD before GET.

I think the problem lies in the fact that HEAD is a special verb in HTTP while its implementation in Web API is not: it has been implemented similar to the rest of the verbs.

In fact, HttpHeadAttribute does not make much sense (neither an action called "Head") since HEAD is nothing but a content-less GET:

"The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request."

So HEAD is actually a special case GET. As such I would expect it to handled by the GET action, only the content is not sent back - no Head action or HttpHeadAttribute.

Is there any plan to implement this as such? I am more than happy to make a Pull Request but I would like to know the view of the team first.

Cheers

Ali

Read the full discussion online.

To add a post to this discussion, reply to this email (ASPNETWebStack@discussions.codeplex.com)

To start a new discussion for this project, email ASPNETWebStack@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

--
-----------------------------------------
Brian Noyes
Chief Architect, IDesign Inc
Microsoft Regional Director / MVP
http://www.idesign.net
+1 703-447-3712
-----------------------------------------



Jun 21, 2012 at 7:58 AM

This will serve as the default implementation by the stack that you could override. At the current stage you have to create a separate a action with separate logic to handle it.

Also, I am not sure how can you guarantee identical headers returned if action does not the same work. In web api you could have a series of message handlers to change the header according to the content. On the other hand a lot of the headers sit on the content itself. Although some resource could be saved by having a separate logic, complexity added to cover all scenarios is not worth it - IMHO.

Jun 21, 2012 at 9:50 AM
Edited Jun 21, 2012 at 9:55 AM

@aliostad is right in my opinion. I am not so much familiar with the spec of HTTP HEAD verb but if the intention is to see the headers of the get request, the Get method should be executed because as Ali indicated,

  • the action method can add/remove headers
  • some of the headers sits inside the HttpContent message
  • the filters can add/remove headers
  • message handlers can add/remove headers

As a result, at first glance, this action may be performed by a message handler (without touching the core implementation) which should be registered as the first message handler. You might be asking why. Here is the reason:

with the latest implementation, message handlers which are registered through HttpConfiguration.MessageHandlers are reversed so that the first registered one runs first as they become a Matryoshka doll (more info on this behavior: http://stackoverflow.com/questions/10251062/asp-net-web-api-message-handlers/11075494#11075494). On the way back (if we provide a continuation method), the continuation method inside the first message handler we have registered will be run at last. So, we can modify the response there according to HTTP HEAD spec.

Jun 21, 2012 at 2:02 PM
Makes sense, thanks for the clarification.

On Thu, Jun 21, 2012 at 3:50 AM, tugberk <notifications@codeplex.com> wrote:

From: tugberk

@aliostad is right in my opinion. I am not so much familiar with the spec of HTTP HEAD verb but if the intention is to see the headers of the get request, the Get method should be executed because as Ali indicated,

  • the action method can add/remove headers
  • some of the headers sits inside the HttpContent message
  • the filters can add/remove
  • message handlers can add/remove headers

As a result, at first glance, this action may be performed by a message handler (without touching the core implementation) which should be registered as the first message handler. You might be asking why. Here is the reason:

with the latest implementation, message handlers which are registered through HttpConfiguration.MessageHandlers are reversed so that the first registered on runs first as they become a Matryoshka doll (more info on this behavior: http://stackoverflow.com/questions/10251062/asp-net-web-api-message-handlers/11075494#11075494). On the way back (if we provide a continuation method), the first message handler we have registered will be run at last. So, we can modify the response there.

Read the full discussion online.

To add a post to this discussion, reply to this email (ASPNETWebStack@discussions.codeplex.com)

To start a new discussion for this project, email ASPNETWebStack@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

--
-----------------------------------------
Brian Noyes
Chief Architect, IDesign Inc
Microsoft Regional Director / MVP
http://www.idesign.net
+1 703-447-3712
-----------------------------------------