Gin: [URGENT, PLEASE HELP]c.AbortWithStatus or c.AbortWithError failed to respond a HEAD request

[beef9999]

curl -v -X HEAD 'http://localhost:9393/test'

< HTTP/1.1 401 Unauthorized
< Date: Thu, 20 Apr 2017 08:10:23 GMT
< Content-Type: text/plain; charset=utf-8
* no chunk, no close, no size. Assume close to signal end

Client sends HEAD request.

The server side, using AbortWithStatus(401) or AbortWithError(401), is able to print a 401 error log.

However the client hangs.

GET method is ok.

[beef9999]

The problem seems to have nothing to do with the error handling, but the current gin release just CAN NOT deal with HTTP HEAD request?

A normal 200 HEAD request would even hang...

[beef9999]

Sorry guys, it's not a bug. It was because I missed to add a "-I" argument when using curl. So the client stuck there waiting for body.

-I, --head
              (HTTP/FTP/FILE) Fetch the HTTP-header only! HTTP-servers feature
              the  command  HEAD which this uses to get nothing but the header
              of a document. When used on an FTP or FILE file,  curl  displays
              the file size and last modification time only.

Although I'm quite astonished that several days passed and nobody came to verify this issue marked as bug. And in the mean time, there are hundreds of open issues outside.

Is this project really dead?

[nazwa]

Hey @beef9999 glad you worked it out! It's not really dead. The framework is still actively developed, but the community side is a bit a bit lacking 😀 I almost had a test case set up for your issue a few days ago, but got massively sidetracked...

[appleboy]

@beef9999 You can see the develop branch for the latest version and we are working on release v1.2 version https://github.com/gin-gonic/gin/pull/871

[beef9999]

@nazwa @appleboy After some further dig, I now believe this issue is still related to a bug...

I compared some of the other web servers, and found that gin didn't have a Content-Length: 0 header when responding to HEAD request, that's why the curl client would hang there waiting for the body.

[nazwa]

@beef9999 After doing some digging, the Content-Length header is a bit of a nifty one when it comes to HEAD requests. The RFC says that it SHOULD be there and contain the actual content length, but then again for dynamic requests that's not always possible to estimate beforehand.

I think this answer explains it really well, and I'm inclined to agree with his reasoning behind no Content-Length in response: http://stackoverflow.com/a/3854983/486780