Bump Browser-Sync to newer version

[bexter89]

should resolve an issue where index.min.js is missing from a few versions

should resolve some console errors 🤞

[mwcz]

I'd love to, but all newer browser-sync versions break (nearly) all spandx tests because it begins returning Content-Length and Transfer-Encoding: chunked in the same response, when those headers are mutually exclusive. See #282

It's possible that browser-sync isn't completely at fault for this, and one of spandx's middleware functions is adding one or the other errant header. @aditiohri and I spent an unreasonable amount of time trying to track down where both headers came from and came up empty (setting breakpoints inside nodejs stdlib functions would be a really nice feature 🤦). If someone is able to figure out where both headers are coming from, it might reveal a better solution than pinning an old version of browser-sync.

[bexter89]

It looks like that version of Jasmine is following an old RFC; see this more recent RFC: https://www.rfc-editor.org/rfc/rfc7230.html

i'm going to experiment with updating jasmine and browser-sync and see if we cant get them to be friendly

[mwcz]

That also forbids the two headers coexisting.

A sender MUST NOT send a Content-Length header field in any message that contains a Transfer-Encoding header field.

[mwcz]

I'm also not sure Jasmine was involved. It doesn't know anything about HTTP. AFAIK it was the HTTP clients (I tried multiple) which were throwing when the response came back with both headers.

[bexter89]

Pardon my naivety here, but do you think maybe it’s Frisby or the HTTP server? I’m wondering like, which part is sending those headers? Also, is it possible that if we use node 17+, we can use fetch and still check all of the reaponse headers with Jasmine (or Jest, since that’s what Frisby is using)?Would be interested in a longer term effort to  modernizing Spandx as a whole a bit to use ESM. On Aug 26, 2023, at 16:46, Michael Clayton ***@***.***> wrote: I'm also not sure Jasmine was involved. It doesn't know anything about HTTP. AFAIK it was the HTTP clients (I tried multiple) which were throwing when the response came back with both headers. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>