@andreterron Thank you for reviewing and merging it but unfortunately, I made an error in the implementation.
https://www.val.town/v/andreterron/fetch_docs?v=9#L12-14 effectively means that requestInit will be discarded if the input is an instance of Request and that doesn't sound right. It prompted me to look elsewhere and see how different fetch implementations/polyfills deal with input + init combo and here's what I found. Basically, the first order of business if you are wrapping (native) fetch is to take both input and requestInit and produce origReq:
I merged your changes into my val and created a PR into @std/fetch :)
@andreterron Thank you for reviewing and merging it but unfortunately, I made an error in the implementation.
https://www.val.town/v/andreterron/fetch_docs?v=9#L12-14 effectively means that
requestInit
will be discarded if the input is an instance ofRequest
and that doesn't sound right. It prompted me to look elsewhere and see how different fetch implementations/polyfills deal with input + init combo and here's what I found. Basically, the first order of business if you are wrapping (native) fetch is to take bothinput
andrequestInit
and produceorigReq
:It can be observed inside:
That's what happens when I'm trying to be too smart instead of opting for the simplest solution 😅
PR with the fix is on the way 🛫