Adding CORS headers to non-CORS-related rejections

[seglo]

I've observed that when a Route rejects a request for a non-CORS related reason this library won't map the rejection response to include CORS headers even when the request is valid from a CORS perspective. The result is that when an error response is returned to a browser the actual body of the response is opaque because of CORS security.

I looked at the CORS spec and nothing caught my attention that would indicate that error responses should be ignored. Do you think it would make sense to add the headers in this case? I can create a PR if you're in agreement.

[lomigmegard]

Hi,
You are indeed correct, but if I understood correctly, I believe this issue has been covered in #19 (and #5). You can also look at the Scala example for a complete example of how errors (exceptions and rejections) should be handled in the inner route (before) the cors directive.

Let me know if this doesn't cover your question.

[lomigmegard]

Follow-up:

To be clear your statement is correct:

I looked at the CORS spec and nothing caught my attention that would indicate that error responses should be ignored. Do you think it would make sense to add the headers in this case?

It has been a long time I designed this directive, from what I remember there was a reason to not automatically "map the rejected" response to include the CORS headers. But instead, to rely on the inner route being sealed. Of course if you have ideas on how to improve that, please share them :)

Cheers

[seglo]

I don't know how I missed #19, sorry for the dupe. Thank you for the pointer to your example. I've been poking around with how this might be handled in the library, but handling rejections in the manner described is good enough for me now. I'll follow up with a PR if I have a different suggestion.