-
Notifications
You must be signed in to change notification settings - Fork 201
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Code optimisations to headers calls #92
Conversation
Directly use case insensitive request.getResponseHeader for the header values checks
|
ooooh you're so right! this is a great optimization. |
Alright I think I found an issue with this approach:
// for an HTTP response like this:
// 200 OK
// Foo: one
// Foo: two
r.getResponseHeader('foo') === 'one, two' In this case I'm not sure how we could feasibly separate the header values. The spec says they're always concatenated using |
@developit wondering why we would need to separate the values? The previous approach would return |
@developit Actually I see the old way didn't combine the values for the entries mthod. That seems to be incorrect. If you run the below code:
|
@developit I think the note here https://fetch.spec.whatwg.org/#headers-class is relevant I've done a bit more research and previously there was a |
Thanks for digging so deeply into this one! I think I was remembering the old One huge perk of the size drop you've managed here is that it gives us room to explore supporting btw - I just spent a week around Cape Town. Nice place! |
Glad to be able to contribute 😊 And thanks, I rather like it here too! |
@developit let me know if you need me to do anything to move this along |
Why was this never merged? |
@RReverser because I'm a bad person! |
Co-authored-by: Simon Buerger <[email protected]> Co-authored-by: Jason Miller <[email protected]>
Alrighty, I merged this manually (had to rewrite the history). Sorry for the (checks watch) 5 year delay! |
A few things to unpack here
As far as I can tell we only need the header keys, we don't actually need to construct the entries and headers objects with combined values, as the method on XMLHttpRequest
getResponseHeader
already does all that. It returns combined values and is case-insensitive. I guess the only risk would be if some older browser hasn't correctly implemented the original spec for it? Don't know if that's the reason you went this route.Also according to spec header keys shouldn't contain duplicates. Ditto for header entries. So I'm checking before pushing new keys to the array
Directly using request.getResponseHeader for the header entries call and has and get checks. Kind of makes this difficult to mock/test as we're relying on the underlying XMLHttpRequest implementations.