set header on HttpError?

[kdwarn]

Hello and thanks for building this framework!

Is there a way to set a header on an HttpError from an endpoint? I don't see a way to do this, but I'm not sure if I'm just missing something. It would be useful at least in the case of returning a 401 UNAUTHORIZED response, which is supposed to include the WWW-AUTHENTICATE header. I think a workaround could be to create and return an Err(Response) instead of Err(HttpError), but there is a lot of convenience and consistency with using HttpError. I've dug a bit into the documentation and code and I'm not sure exactly where the HttpError is turned into a Response (the documentation for HttpError says "When these bubble up to the top of the request handling stack (which is most of the time that they’re generated), these are turned into an HTTP response"), but I think if a headers field (a Vec of &HeaderMap<HeaderValue>) were added to HttpError it could be handled/set there.

[davepacheco]

I don't think there's currently a way to do this. Yes, we've wanted the same thing for www-authenticate.

We added support for both structured and unstructured headers on successful responses in #283. We may want to do something similar here -- i.e., maybe the OpenAPI spec for the 401 response should say that it includes this header? I'm not sure.

I believe this is where the error is turned into a response:

dropshot/dropshot/src/server.rs

Line 827 in 6151bb4

let r = error.into_response(&request_id);

which calls:

dropshot/dropshot/src/error.rs

Lines 235 to 267 in 6151bb4

	/// Generates an HTTP response for the given `HttpError`, using `request_id`
	/// for the response's request id.
	pub fn into_response(
	self,
	request_id: &str,
	) -> hyper::Response<hyper::Body> {
	// TODO-hardening: consider handling the operational errors that the
	// Serde serialization fails or the response construction fails. In
	// those cases, we should probably try to report this as a serious
	// problem (e.g., to the log) and send back a 500-level response. (Of
	// course, that could fail in the same way, but it's less likely because
	// there's only one possible set of input and we can test it. We'll
	// probably have to use unwrap() there and make sure we've tested that
	// code at least once!)
	hyper::Response::builder()
	.status(self.status_code)
	.header(
	http::header::CONTENT_TYPE,
	super::http_util::CONTENT_TYPE_JSON,
	)
	.header(super::http_util::HEADER_REQUEST_ID, request_id)
	.body(
	serde_json::to_string_pretty(&HttpErrorResponseBody {
	request_id: request_id.to_string(),
	message: self.external_message,
	error_code: self.error_code,
	})
	.unwrap()
	.into(),
	)
	.unwrap()
	}
	}

It'll take some thought to figure out how to best express this in a compatible way.