Ability to set Response Headers

[Ayrx]

Hi,

I would like the ability to set specific HTTP response headers on specific endpoints. E.g. it would be nice to have the ability to set a Content-Disposition header at specific endpoints to trigger a file download when accessed via a browser.

I do not see this currently exposed in the API anywhere but maybe I missed something.

[ahl]

Hey @Ayrx -- you're right: not something we support today. We'll be happy to take a look, but let us know if there's some particular way you think this would work well from consumer code.

[Ayrx]

I haven't actually looked at the implementation of the macro and Dropshot in general so I'm not sure if it is actually feasible but I'd be happy with a string-interface similar to the following:

#[endpoint {
    method = GET,
    path = "/foo",
    headers = "Content-Disposition: xxx; X-Random-Header: xxx",
}]
async foo(

In addition, it would be nice to have a method on HttpServer to add a header that applies to all endpoints since I understand that dropshot is intended to be used as a standalone HTTP server and not used behind something like nginx as a proxy:

server.add_header("X-Random-Header", "XXX");

As far as resolving conflicting headers, I think having headers defined at a API level overriding globally defined header values should work fine.

[mx-shift]

Attribute and server method mechanisms work for staticly defined header values. Dynamic items like ETag or CORS allowed origins with Vary: Origin need something different. Rick

…

On Wed, Oct 14, 2020 at 7:02 PM Terry Chia ***@***.***> wrote: I haven't actually looked at the implementation of the macro and Dropshot in general so I'm not sure if it is actually feasible but I'd be happy with a string-interface similar to the following: #[endpoint { method = GET, path = "/foo", headers = "Content-Disposition: xxx; X-Random-Header: xxx", }]async foo( In addition, it would be nice to have a method on HttpServer to add a header that applies to all endpoints since I understand that dropshot is intended to be used as a standalone HTTP server and not used behind something like nginx as a proxy: server.add_header("X-Random-Header", "XXX"); As far as resolving conflicting headers, I think having headers defined at a API level overriding globally defined header values should work fine. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#57 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACIEHF4D5Z4EI5ALNB756FDSKZJZTANCNFSM4SQSDGCA> .

[arun-koshy]

Is there any update on this? I am trying to find out the right way to do something similar for CORS headers using dropshot

I currently seem to be able to get responses via Fetch API if I use the following handler response

Response::builder() .status(StatusCode::OK) .header(http::header::CONTENT_TYPE, CONTENT_TYPE_JSON) .header(http::header::ACCESS_CONTROL_ALLOW_ORIGIN, "*") .body(body)?;

However I still see an error in the server logs with the OPTIONS preflight request

INFO request completed, error_message_external: Method Not Allowed, error_message_internal: Method Not Allowed, response_code: 405, uri: /addresses, method: OPTIONS, req_id: f0323b5a-6880-42c6-9bcb-add513d80751, remote_addr: 127.0.0.1:58042, local_addr: 127.0.0.1:5000

[ahl]

I believe that #276 may address the needs described initially in this issue both via headers expressed in the OpenAPI description and ad hoc headers.

@arun-koshy I think we may need more context to understand the pathology you're describing. Does your code work if you omit the .header() calls?

[arun-koshy]

If I omit .header(http::header::ACCESS_CONTROL_ALLOW_ORIGIN, "*") the response will not be accepted by Fetch API. This is because of CORS. According to this article to get around that you need to include the header above.

If I do a simple GET request with the header I believe everything is fine. But if it is not a simple request, I think the '405: Method Not Allowed' error I am seeing with the header included may be a result of CORS support not being available in Dropshot? Specifically the OPTIONS method not being supported?

Does dropshot have something similar to how rocket solves this with the rocket_cors crate