set header exception about serverless-dns HOT 10 CLOSED

To be clear (on point 3 above), you're free to choose the solution here you think is best. As long as it works, I mean.

from serverless-dns.

It's interesting, that this is not happening with successful dns queries.

Happens with 302. (redirect, comes out as 503 with this err)

Even though it throws error in the loop (at first iteration), all 3 headers are magically set in the response!!! 503 response has another response constructor at:

I fail to understand this behavior.

❯ curl -v \
  'http://localhost:8787/config' \
  -H 'User-Agent: Mozilla/5.0 something' --output -

* Connected to localhost (127.0.0.1) port 8787 (#0)
> GET /config HTTP/1.1
> Host: localhost:8787
> Accept: */*
> User-Agent: Mozilla/5.0 something
> 

< HTTP/1.1 503 Service Unavailable
< date: Thu, 30 Dec 2021 13:42:28 GMT
< content-type: application/json
< content-length: 159
< connection: keep-alive
< access-control-allow-origin: *
< access-control-allow-headers: *
< access-control-allow-methods: GET, POST, OPTIONS

< vary: Accept-Encoding
< 
* Connection #0 to host localhost left intact
"TypeError: Can't modify immutable headers.\n    at currentRequest_CurrentRequest.setCorsHeaders (worker.js:7182:33)\n    at proxyRequest (worker.js:10137:57)"%

from serverless-dns.

fixed!

from serverless-dns.

@ignoramous

The TypeError is coming from Headers Guard set to "immutable". See: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#guard . It is not exposed, so we can't check if a Response is immutable...

The 302 redirect response which has an "immutable" header comes from it being constructed with Response.redirect() method.

which sets the headers guard to "immutable". See: https://fetch.spec.whatwg.org/#dom-response-redirect (Step 4)

Also, CORS headers makes sense for only 2xx responses according to this: https://fetch.spec.whatwg.org/#cors-preflight-fetch (Step 7)

from serverless-dns.

Nice find. We should create headers when Response obj is constructed to avoid runtime issues?

from serverless-dns.

Creating a new Response there would solve the issue too:

this.httpResponse = new Response(this.httpResponse.body, {
  headers: util.concatHeaders(
    this.httpResponse.headers,
    util.corsHeaders()
  ),
});

Or a try catch ? (I prefer).

from serverless-dns.

try-catch as a conditional? Doesn't fit. Better to not rely on Response.Headers.set working at all, since the API is clearly demarcated off-limits in the documentation.

from serverless-dns.

try-catch as a conditional?

No, like catch TypeErr if gaurd is set. Or creating a new response is better?

Better to not rely on Response.Headers.set working at all, since the API is clearly demarcated off-limits in the documentation.

I still don't agree with that, "The headers read-only property of the Response interface", says only about the "property" being read-only.

from serverless-dns.

I prefer doing the most consistent thing rather than complect the code with conditionals / guards, try-catch, what have you.

1. These CORS headers added for tests are a maintenance burden.
2. Setting the headers at the time Response obj is instantiated is guaranteed to work in all cases (except for forbidden headers).
3. Headers.set isn't even a critical design decision to be bike shedding about.

from serverless-dns.

I believe there's nothing much to do here?

from serverless-dns.