Excel, and others often issue HEAD requests (particularly when asking for metadata) to see if anything has changed.
Currently HEAD is an unsupported method.
As a workaround (non-optimal), you can implement a DelegatingHandler message handler and override SendAsync (lots of example online about how to override and insert a message handler in the configuration).
Before the base.SendAsync() call, you can then do something like the following:
bool isHead = request.Method == HttpMethod.Head;
if (isHead)
request.Method = HttpMethod.Get;
Which will change HEAD -> GET. After the call you can then blank the response:
if (isHead)
{
// We are head request, so blank the content.
response.Content = null;
}
Hope that helps someone else.
Comments: Wow, nice triage there. Pushed out to vNext without so much as a comment? I can kind of accept the 'the workaround is liveable' argument (if you bothered to make an argument) however I would have thought a 'works in Excel' is a pretty vital RTM goal. This bug is pretty easy to fix in the first instance, though for many developers it is likely to stump them long before they found this thread. Without HEAD support (at least on the service document) Excel will simply not work with the service. Ironically I don't need the Excel support, I just came across the issue because I actually tested my service against the popular OData consumers (and so also found the LINQPad bugs). It is not a strange goal for you to ensure that this project will produce services that work in the most popular consumers. This is my first attempt at reporting some of the numerous issues I've found (I have loads more), I've wasted lots of time analysing the problems, making them repeatable and suggesting workarounds and fixes for the benefit of the community as a whole, it only takes a minute to write a one line comment explaining your decision, and in doing so you would encourage further engagement. TL;DR Please let me encourage you to add the human touch and explain decisions.
Currently HEAD is an unsupported method.
As a workaround (non-optimal), you can implement a DelegatingHandler message handler and override SendAsync (lots of example online about how to override and insert a message handler in the configuration).
Before the base.SendAsync() call, you can then do something like the following:
bool isHead = request.Method == HttpMethod.Head;
if (isHead)
request.Method = HttpMethod.Get;
Which will change HEAD -> GET. After the call you can then blank the response:
if (isHead)
{
// We are head request, so blank the content.
response.Content = null;
}
Hope that helps someone else.
Comments: Wow, nice triage there. Pushed out to vNext without so much as a comment? I can kind of accept the 'the workaround is liveable' argument (if you bothered to make an argument) however I would have thought a 'works in Excel' is a pretty vital RTM goal. This bug is pretty easy to fix in the first instance, though for many developers it is likely to stump them long before they found this thread. Without HEAD support (at least on the service document) Excel will simply not work with the service. Ironically I don't need the Excel support, I just came across the issue because I actually tested my service against the popular OData consumers (and so also found the LINQPad bugs). It is not a strange goal for you to ensure that this project will produce services that work in the most popular consumers. This is my first attempt at reporting some of the numerous issues I've found (I have loads more), I've wasted lots of time analysing the problems, making them repeatable and suggesting workarounds and fixes for the benefit of the community as a whole, it only takes a minute to write a one line comment explaining your decision, and in doing so you would encourage further engagement. TL;DR Please let me encourage you to add the human touch and explain decisions.