Hi @jasnell! Could you please review this PR?

I'm excited and eager to contribute to this project. While browsing the issues, I noticed that #3066 was proposed without a corresponding PR. I decided to address it.

I’m still trying to fully understand the issue (so the PR is still a WIP). I see that both EW_URL_ISOLATE_TYPES (from url.h) and EW_URL_STANDARD_ISOLATE_TYPES (from url-standard.h) are registered in the runtime. They seem similar, but url.h is not compliant with the WHATWG standard. Will they conflict, or does the latter override the former?

I suspect the problem arises because EW_URL_STANDARD_ISOLATE_TYPES overrides EW_URL_ISOLATE_TYPES, causing api::URLSearchParams to not match the JavaScript URLSearchParams object. As a result, the JavaScript URLSearchParams is coerced into a kj::String, leading to the content-type header error. I'm not very sure about that because the codebase is not easy to understand. If there is anything wrong, please correct it for me. :)

Hi, @jasnell. I’ve force-pushed an update to add the missing jsg::Ref<url::URLSearchParams> in Body::Initializer. I’ve tested both versions with different compatibilityDate, and they both worked well. I also added you as a co-author in the commit message and hope you don’t mind.

@balusch ... thank you for the fix! Really appreciated!

Looks like some linting issues with this. I'll fix those up and get this landed.

hmm, actually that passed linting locally. Maybe a CI issue. Let me rerun CI.

CI seems unwell, but looks more like for unrelated network/cache issues... hope those resolve again

ah, ok, I see, there's an issue with our automatic type generation with two URLSearchParam definitions conflicting. We'll need to resolvre that before this can land.

@penalosa said that he'd take a look at what needs to be updated here to fix the type gen issue.

Not to bikeshed some more, but I updated this to fix the comment line length (workerd uses KJ style and thus 100) and use links to the latest tagged release which are shorter.