Skip to content

Conversation

@JavierJF
Copy link

@JavierJF JavierJF commented May 13, 2022

Identify the Bug

#268

Description of the Change

The change is simple, instead of calling 'MHD_destroy_post_processor' in the destructor after the request has been processed, it's called before calling the registered processing callback.

Alternate Designs

I haven't think in alternate designs. I chose to call 'MHD_destroy_post_processor' right before mr->callback because I think it's the only place requiring of the final post processing of the request. Thus, keeping the two operation close makes sense.

Possible Drawbacks

If all the information is going to be used just by mr->callback, can't think of any drawback.

Verification Process

Sorry, internal testing, just testing over the endpoints in a third party application.

Release Notes

  • Fixed processing of final keys without values for POST body processing of kind 'application/x-www-form-urlencoded'

'MHD_destroy_post_processor' should be called before the request
callback for ensuring the processing of final keys without terminated
values.
@JavierJF JavierJF force-pushed the fix_post_process branch from a2dece8 to c2f6d28 Compare May 13, 2022 15:44
if (found) {
try {
if (hrm->is_allowed(method)) {
if (mr->pp != NULL) {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: can we use nullptr instead of NULL

Copy link
Owner

@etr etr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fix. Looks good overall - I left you a nitpicky comment about NULL vs nullptr.

I think the only missing thing is a test proving the use-case you spotted and the fact that it now works.

etr added a commit that referenced this pull request Jan 27, 2026
Destroy post processor before invoking the callback to ensure pending
POST body keys with empty values are properly finalized. Without this,
POST data like "arg1=val1&arg2=" would fail to include arg2.

The fix moves MHD_destroy_post_processor call to finalize_answer()
before the resource callback is invoked, rather than waiting for
the modded_request destructor.

Added test cases verifying:
- arg1=val1&arg2= correctly parses both args
- arg1= correctly parses as empty string
- arg1=&arg2= correctly parses both as empty strings

This supersedes PR #269 with the requested code style changes.
@etr
Copy link
Owner

etr commented Jan 27, 2026

This PR has been superseded by #351, which includes the requested changes (using nullptr instead of NULL) and adds test cases to verify the fix. Thank you for the original contribution!

@etr etr closed this Jan 27, 2026
etr added a commit that referenced this pull request Jan 27, 2026
Destroy post processor before invoking the callback to ensure pending
POST body keys with empty values are properly finalized. Without this,
POST data like "arg1=val1&arg2=" would fail to include arg2.

The fix moves MHD_destroy_post_processor call to finalize_answer()
before the resource callback is invoked, rather than waiting for
the modded_request destructor.

Added test cases verifying:
- arg1=val1&arg2= correctly parses both args
- arg1= correctly parses as empty string
- arg1=&arg2= correctly parses both as empty strings

This supersedes PR #269 with the requested code style changes.
etr added a commit that referenced this pull request Jan 27, 2026
* Fix POST args with empty values not being parsed (issue #268)

Destroy post processor before invoking the callback to ensure pending
POST body keys with empty values are properly finalized. Without this,
POST data like "arg1=val1&arg2=" would fail to include arg2.

The fix moves MHD_destroy_post_processor call to finalize_answer()
before the resource callback is invoked, rather than waiting for
the modded_request destructor.

Added test cases verifying:
- arg1=val1&arg2= correctly parses both args
- arg1= correctly parses as empty string
- arg1=&arg2= correctly parses both as empty strings

This supersedes PR #269 with the requested code style changes.

* Fix Windows build: replace rand_r with portable rand()

rand_r is POSIX-specific and not available on Windows. Since this is
just a stress test where thread-safe randomness isn't critical, use
the portable rand() function instead.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants