CODEWITHSUNDEEP
javascriptformsrestpostnetwork-programming
Alex Borodin
Alex Borodin

Reputation: 2034

Is using a query string in POST request a bad practice?

There is a system that sends POST requests from frontend to backend. These POST requests do not use the body to pass the data to the server; instead, it uses query strings in the URL params.

These requests do not send files or JSON, only several string params.

W3C does not describe that situation https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Is it a bad practice to use query strings for POST requests, and if there any negative consequences of using that from security or performance or architecture reasons?

Are there any conventions that define the usage of body or query strings for different types of requests?

Upvotes: 7

Views: 14236

Answers (2)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57289

Reminder: In 2014, RFC2616 was replaced by multiple RFCs (7230-7237).

Is using a query string in POST request a bad practice?

Not if you know what you are doing.

Mechanically, it is all fine: are we allowed to use POST with a target-uri that includes a query-part? Yes. Are we allowed to use POST with an empty request body? Yes. Are we allowed to do both of those things at the same time? Yes.

The hard part: will this POST request invalidate the correct representations from the cache?

Cache-invalidation happens when the server returns a non-error response to an unsafe request (POST is an unsafe request method). The representations that are invalidated are those that match the target-uri of the unsafe request.

GET /foo?a=b HTTP/2.0
POST /foo?a=b HTTP/2.0

Here, if the POST is successful, the representations cached after the successful GET request will be invalidated in the cache.

GET /foo HTTP/2.0
POST /foo?a=b HTTP/2.0

Here, the effective request-uri is not the same, which means that general purpose components won't invalidate the cached representations of /foo.

Upvotes: 7

deceze
deceze

Reputation: 522480

There's nothing wrong with using query parameters in a URL in a POST request, with or without a request body. If it makes semantic sense for your request, it's fine. The POST method in itself has a semantic meaning distinct from GET, it doesn't require a request body to be useful, and the URL is yet distinct from that again. A classic example might be:

POST /foo/bar?token=83q2fn2093c8jm203

I.e., passing some sort of token through the URL.

There's no general security problem here, since anyone who could intercept this POST request to read the URL could also read its body data; you'll hardly find an attacker in a position that allows them to read the URL but not the body. However, URLs are typically logged in server access logs and browser histories, while request bodies aren't; that may or may not be worth considering, depending on what information you're transporting in those parameters and who has access to those logs.

Upvotes: 5

Related Questions