Add configs to choose between ecoding parameters in the URL or request body #1525
Conversation
Even though the semantics of request bodies for GET and DELETE are undefined, it is legal to set request bodies for them. By default, GET and DELETE 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 and DELETE methods, just like it does for all the other HTTP methods.
alexpetros
force-pushed
the
get-and-delete-body-extension
branch
from
b9403d8
to
0baa329
Compare
alexpetros
changed the title
|
@1cg updated and ready for review |
alexpetros
changed the title
alexpetros
changed the title
src/htmx.js
Outdated
| useUrlParams = false | ||
| } | ||
| }) | ||
|
|
There was a problem hiding this comment.
think we can drop this now? I don't like signaling this via the presence of a function, would rather the extension do so via the htmx:configRequest event if necessary...
There was a problem hiding this comment.
Yup that's smart, done.
|
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 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. |
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
GETrequests that havejson-encenabled, and this PR fixes the brokenDELETEone.