Avoid bubbling errors on getResponseHeader on forbidden headers #2057
Conversation
carlopi
force-pushed
the
try_catch_getresponseheaders
branch
from
3378a82 to
51b5481
Compare
| const contentRange = xhr.getResponseHeader('Content-Range')?.split('/')[1]; | ||
| const contentLength2 = xhr.getResponseHeader('Content-Length'); | ||
| let actualContentLength = null; | ||
| try { actualContentLength = xhr.getResponseHeader('Content-Length'); } catch (e: any) {console.warn(`Failed to get Content-Length on request`);} | ||
| const contentRange = actualContentLength?.split('/')[1]; | ||
| const contentLength2 = actualContentLength; | ||
|
|
There was a problem hiding this comment.
@carlopi I stumbled on this changed while trying to understand why duckdb-wasm seemed unhappy with the behaviour of my server.
This change means that the code now looks for the actually content length in the Content-Length header (by splitting on /) instead of the previous behaviour of looking for it in the Content-Range.
I believe the pre-diff behaviour is correct, as Content-Length shouldn't contain a / and shouldn't send the full content length.
Should I open a PR to suggest a fix ?
See:
There was a problem hiding this comment.
Hey! thanks for digging in, this looks like it's a problem, not great, a PR with a suggested fix would be great!
There was a problem hiding this comment.
OK, thanks for the quick reply ! Here's a PR: #2123
I tried to stay as close to the original code as I could
2 participants
No description provided.