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

HEAD Request Directives not processing when transparent-head-requests on #27

Open
EdgeCaseBerg opened this issue Aug 10, 2015 · 7 comments

Comments

@EdgeCaseBerg
Copy link

Hello!

I think I may have found a bug when dealing with HEAD requests to spray-can. The documentation states:

By default, spray-can handles HEAD-requests transparently by dispatching a GET-request to the handler and stripping of the result body. See the spray.can.server.transparent-head-requests setting for how to disable this behavior.

But it doesn't say that the head directives won't be processed as all when the setting is on. I've made an example repository with instructions on how to reproduce what I see as an error or undocumented "feature" here

The steps to reproduce are in the README file in the linked example. Is this the expected behavior? If so, where is it documented?

@EdgeCaseBerg
Copy link
Author

Also, is this the right repository for this bug report? I assumed it was since the setting is spray.can.server and not something in spray routing

@jrudolph
Copy link
Member

Nope, this is a very old legacy repository :)

This is also not a bug. As you quoted yourself, transparently-handled HEAD requests are dispatched to your application as GET requests. That's what this feature is all about. In the example, you need to react to GET requests to v0/healthcheck once you enable transparent head requests. So, it's exactly the head directive which prevents that the request is handled.

@jrudolph
Copy link
Member

So, in summary, with spray.can.server.transparent-head-requests="on" you will never see any HEAD requests (they are transparent) but they will look to you like GET requests.

@EdgeCaseBerg
Copy link
Author

I was surprised because while I expected the transparent GET requests, I didn't think that it would result in the head directives being ignored entirely for a route I only wanted to respond to HEAD requests. That wasn't totally clear to me from the documentation that it replaced the functionality, I just thought it added additional

@EdgeCaseBerg
Copy link
Author

But isn't the tests passing no matter the setting (even with sealedRoutes) kind of misleading?

@jrudolph
Copy link
Member

That's because tests built with the testkit are executed without spray-can and so transparent-head-request handling isn't available. I agree that this is unfortunate as it prevents proper testing of the behavior.

@EdgeCaseBerg
Copy link
Author

I assume that there's no way currently to somehow bring that handling into scope in some way while doing tests? Short of actually running a spray-can instance and performing real HTTP requests against it.

It's not a big deal, since it does make sense now that you've explained that the transparent head requests replaces the head behavior with get. But I think it might be a nice todo if the documentation could be a bit more explicit about that. Maybe instead of saying: "handles HEAD-requests transparently by dispatching a GET-request", "handles HEAD-requests transparently by dispatching a GET-request instead of a HEAD request. It is not possible to unit test HEAD-only routes that do not have a corresponding GET route..."

Or some better-worded version of that. I'm sure it's not a typical use case to have a resource support HEAD and not GET so maybe it's not neccesary. But on the other hand, the inability to test that is, as you say, unfortunate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants