Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP HEAD considerations #314

Closed
dustinmoris opened this issue Oct 10, 2018 · 4 comments
Closed

HTTP HEAD considerations #314

dustinmoris opened this issue Oct 10, 2018 · 4 comments
Labels
feature request Request to add new functionality question General question refactoring request Request to improve code without changing external APIs (e.g. perf improvements)

Comments

@dustinmoris
Copy link
Member

A few things which I'm trying to get clarity on:

  • Should Giraffe have a handler like verbs [ GET, HEAD ] >=>?
  • Should Giraffe's GET handler also handle HEAD requests?
  • Should Giraffe's response writers (e.g. json, htmlFile, etc.) check if a request is a HEAD and only write to the response body if it isn't a HEAD?
  • Is there a scenario where someone would want to serve a HTTP GET request but not serve the same request via HEAD?

Would love to get some input on how current Giraffe users feel about this!

@dustinmoris dustinmoris added feature request Request to add new functionality question General question refactoring request Request to improve code without changing external APIs (e.g. perf improvements) labels Oct 10, 2018
@dustinmoris
Copy link
Member Author

Should Giraffe's response writers (e.g. json, htmlFile, etc.) check if a request is a HEAD and only write to the response body if it isn't a HEAD?

Not required. A HEAD response should never contain a body, but this seems to be already handled by ASP.NET Core.

@dustinmoris
Copy link
Member Author

Should Giraffe have a handler like verbs [ GET, HEAD ] >=>?

This is already done: choose [ HEAD; GET ] works just fine.

@cmeeren
Copy link

cmeeren commented Dec 12, 2018

I am surprised and very happy to learn that this is so trivial to implement. I suggest two very simple changes:

  1. Add a note about this to the documentation (not sure where it would fit; you probably have a better idea than me.)

  2. Add a GETH handler that is simply defined as choose [ GET; HEAD ]. Yes, it's so trivial that people can easily define it themselves, but if we define it in the library, there's one standard handler to support combined GET/HEAD endpoints, and Giraffe codebases will be more standardized when it comes to supporting both GET and HEAD requests for an endpoint. And of course, being so trivial there's no extra maintenance on your part.

@dustinmoris
Copy link
Member Author

@cmeeren: Coming in the next version: ea9054d

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Request to add new functionality question General question refactoring request Request to improve code without changing external APIs (e.g. perf improvements)
Projects
None yet
Development

No branches or pull requests

2 participants