htmx
htmx copied to clipboard
Add configs to choose between ecoding parameters in the URL or request body
Summary
Even though the semantics of request bodies for GET are undefined, it is legal to set request bodies for them. By default, GET form parameters should be encoded as URLs. If, however, an extension defines encodeParameters, that should override the default and set the request bodies for GET methods, just like it does for all the other HTTP methods.
Resolves: #1514, #1539
Testing
Wrote some new unit tests for GET requests that have json-enc enabled, and this PR fixes the broken DELETE one.
@1cg updated and ready for review
thx @alexpetros!
So I found this PR (and related issues) after searching for why my Go backend didn't accept the form data that HTMX sends in a DELETE request.
According to this stackoverflow post: https://stackoverflow.com/a/59011736
Sending a body in a DELETE request is non-standard and cannot be expected to work. Indeed the body is ignored by Golangs request.ParseForm() method.
It looks like this PR didn't just make the behavior of DELETE requests configurable, which is fine, but also changed their default behavior from the normal and preferred way of encoding parameters in the URL to sending them in the body. This is now an issue for Golang users such as myself, and surely for other languages or libraries as well.
Am i misinterpreting something or should the default behavior for DELETEs be reverted back to encoding in URL query params?
It looks like this PR didn't just make the behavior of DELETE requests configurable, which is fine, but also changed their default behavior from the normal and preferred way of encoding parameters in the URL to sending them in the body. This is now an issue for Golang users such as myself, and surely for other languages or libraries as well.
Am i misinterpreting something or should the default behavior for DELETEs be reverted back to encoding in URL query params?
Yes, you're wrong about the second part—htmx has always sent DELETE bodies by default, that's what inspired the PR in the first place. This default is being changed in 2.0 to the behavior that you're requesting, but in the meantime, you can configure it using the config that was implemented here.
Thank you for clarifying, I just misinterpreted the diff here. I implemented the config to mitigate the issue.