Use POST like a GET? #2669

darksylinc · 2023-12-08T22:27:51Z

darksylinc
Dec 8, 2023

Hi!

Rocket supports the following:

#[put("/auth/authenticateUser?<username>&<password>&<game>")]
async fn authenticate_user(
    username: Option<&str>,
    password: Option<&str>,
    game: Option<&str>,
) -> Result<StoredData, ServerError> {
   return Ok("");
}

And it works exactly as I want and expect.

However what I'm having trouble with (and I'm not sure if it's possible) is what happens if the 3 parameters are sent through POST instead of GET.

I managed the following to work:

#[derive(Debug, Clone, FromForm, Serialize, Deserialize)]
#[cfg_attr(test, derive(PartialEq, UriDisplayQuery))]
#[serde(crate = "rocket::serde")]
struct AuthParam<'a> {
    pub username: Option<&'a str>,
    pub password: Option<&'a str>,
    pub game: Option<&'a str>,
}

#[post("/auth/authenticateUser", data = "<form>")]
async fn authenticate_user(form: Form<AuthParam<'_>>) -> Result<StoredData, ServerError> {
   return Ok("");
}

I confirmed it works correctly. I haven't yet played enough with this, I probably want to add a Strict<>.

However what I want to ask: is there a way to tell Rocket to use the first way? I would like to avoid the hassle of defining a struct for each POST argument for each function (the API is already like this).
Basically something like the following (not valid code):

#[post("/auth/authenticateUser", data = "<username>&<password>&<game>")]
async fn authenticate_user(
    username: Option<&str>,
    password: Option<&str>,
    game: Option<&str>,
) -> Result<StoredData, ServerError> {
   return Ok("");
}

I read in the documentation that Rocket has a _method workaround that sounds like what I want:

Because web browsers only support submitting HTML forms as GET or POST requests, Rocket reinterprets request methods under certain conditions. If a POST request contains a body of Content-Type: application/x-www-form-urlencoded and the form's first field has the name _method and a valid HTTP method name as its value (such as "PUT"), that field's value is used as the method for the incoming request. This allows Rocket applications to submit non-POST forms.

However:

I'm not sure if this is what I'm looking for; perhaps I completely misunderstood what it does.
I could not get this to work.
It sounds a bit weird (and a slight red flag) that server routing mechanisms are left to the client to control. Furthermore there is no need to waste bandwidth on something the server should already know.

So the TL;DR:

Is it possible to have the url encoded data sent through POST be handled as regular arguments as they are with GET?
- Is the _method alternative meant to achieve this?
Or do I need to resign myself to writing a struct for each API whose arguments are sent through POST?

Thanks!

DavidSkrundz · 2023-12-09T16:51:14Z

DavidSkrundz
Dec 9, 2023

Simply changing put to post worked for me.

#[rocket::post("/auth/authenticateUser?<username>&<password>&<game>")]
async fn authenticate_user(
	username: Option<&str>,
	password: Option<&str>,
	game: Option<&str>,
) -> Result<&'static str, ()> {
	println!("{:?}", username);
	println!("{:?}", password);
	println!("{:?}", game);
	return Ok("");
}

I used this curl request to verify the prints are correct:

curl -X POST 'https://localhost/auth/authenticateUser?username=test&password=1234&game=four'

4 replies

darksylinc Dec 9, 2023
Author

curl -X POST 'https://localhost/auth/authenticateUser?username=test&password=1234&game=four'

That command sent username, password and game through GET, not through POST.

The following HTML example sends through POST:

<html>
<form action="http://localhost:8000/auth/authenticateUser" method="post">
    <input type="hidden" id="username" name="username" value="Hello">
    <input type="hidden" id="password" name="password" value="1234">
    <input type="hidden" id="game" name="game" value="four">
    <input type="submit" value="Submit">
</form>
</html>

and successfully matches the route to call the rust function, but the outputs are:

None
None
None

The correct command through Curl to emulate what the browser is doing would be:

curl -X POST http://localhost:8000/auth/authenticateUser -H "Content-Type: application/x-www-form-urlencoded" -d "username=Hello&password=1234&game=four"

blackghost1987 Dec 9, 2023

I think you are confusing the concepts of HTTP Methods and the different ways of sending data in a HTTP request. You can use Query params (parameters encoded in the URL) and Form data (data sent in the HTTP body) with any HTTP method you want. Actually you can mix and match the two as well, you could have Query parameters AND body data in the same request.

When you want to process this request with Rocket, the parameters in the URL are mapped to the function parameters by name, and the whole body of the request is mapped to a single function parameter (which name is defined by the "data =" part in the annotation). This has nothing to do with the selected HTTP Method at all, you can have these in GET / PUT / POST or whatever requests.

The format of the HTTP Body can be multiple things, so you have to tell Rocket how to parse it, via using the proper type. It can be a Form, JSON, or even plaintext or binary data. The Struct is needed to determine the "inner structure" of the Form body, but not every body type has an "inner structure" with multiple fields like this, it could be even a single value.
So the mapping to multiple fields as you propsed cannot be done, also you wouldn't have a singular place to set to type for body parsing with many fields like that.

I get why you would like to have a similar interface for the two routes, but it's not possible the way you described. You could achieve a similar interface in the opposite way though, by mapping all the Query parameters into a single variable through a struct. See the followig link for an example: https://rocket.rs/v0.5/guide/requests/#trailing-parameter

If you only specify a single parameter in the URL, you could in theory use the same Struct for Query parameters and Form bodies.

Something like this (warning: code not compiled or tested, just a guideline)

#[derive(Debug, Clone, FromForm, Serialize, Deserialize)]
#[cfg_attr(test, derive(PartialEq, UriDisplayQuery))]
#[serde(crate = "rocket::serde")]
struct AuthParam<'a> {
    pub username: Option<&'a str>,
    pub password: Option<&'a str>,
    pub game: Option<&'a str>,
}

#[post("/auth/authenticateUser", data = "<form>")]
async fn authenticate_user_post(form: Form<AuthParam<'_>>) -> Result<StoredData, ServerError> {
   return Ok("");
}

#[put("/auth/authenticateUser?<userData..>")]
async fn authenticate_user_put(userData: AuthParam<'_>) -> Result<StoredData, ServerError> {
   return Ok("");
}

Would this help?

SergioBenitez Dec 9, 2023
Maintainer

Great comments from others! But just to add: if you control the client, then why not send a GET request? In your example HTML, for instance, changing method=post to method=get would suffice.

But to the actual point: the primary difference between form data in a post and a get, from the server's perspective, is the existence of an arbitrarily long, arbitrarily formatted payload in one (post) and not the other (get). This means that Rocket needs to allow data parsers of any kind, not only forms. Adding special syntax for data forms would be doing just that: special casing the format without semblance of generality. This is in contrast to form data in query strings in GET requests, which must be formatted as URL encoded form data and cannot exceed a given length, bounded by the length of the complete URL. As such, Rocket's syntax there is directly mirroring the specification.

Defining a structure adds a couple of lines of overhead, but it enables us to generate a parser that works for all forms in the data payload (IE, multipart forms as well). It also allows you to add arbitrary validation to form fields, and to reuse that structure. That being said, if we could come up with nice syntax that works for any kind of body data and removes the need to define a structure, I would be open to its addition to Rocket. But that bar is high. Any additional syntax adds cognitive overhead, perhaps the scarcest resource we have.

darksylinc Dec 10, 2023
Author

I think you are confusing the concepts of HTTP Methods and the different ways of sending data in a HTTP request. You can use Query params (parameters encoded in the URL) and Form data (data sent in the HTTP body) with any HTTP method you want. Actually you can mix and match the two as well, you could have Query parameters AND body data in the same request.

Fair enough. Phrased differently, I wanted to know if form data can be configured in Rocket to be treated the same way as Query params.

But to the actual point: the primary difference between form data in a post and a get, from the server's perspective, is the existence of an arbitrarily long, arbitrarily formatted payload in one (post) and not the other (get).

Ahh!! I see the problem. Makes sense. Thanks for clarifying this!

That being said, if we could come up with nice syntax that works for any kind of body data and removes the need to define a structure, I would be open to its addition to Rocket. But that bar is high. Any additional syntax adds cognitive overhead, perhaps the scarcest resource we have.

I don't really need something that complex. Would it be feasible to ask Rocket "do the same you're doing with GET queries, but the answer comes in the POST body? (and anything that doesn't conform is a either a warning, gets dropped or 4xx/5xx error)"

But just to add: if you control the client, then why not send a GET request? In your example HTML, for instance, changing method=post to method=get would suffice.

Yes and no. The client is written in C++ using libcurl (it's not through a browser); and although I control the client; I am trying to see how much backwards compatible the new server can be; and even if it cannot; how much I need to modify everything.

Ultimately my question boiled down to a convenience problem (not having to define a struct for every single function that required it) rather than a "oh no, I can't do it".

Having a fn my_function( arg0 : u64, arg1 : u32 ) is very convenient & clean when the client does already guarantee the POST parameters are encoded the same way as GET query params.

Thanks for all the replies so far!

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use POST like a GET? #2669

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 1 comment 4 replies

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

Select a reply

Use POST like a GET? #2669

darksylinc Dec 8, 2023

Replies: 1 comment · 4 replies

DavidSkrundz Dec 9, 2023

darksylinc Dec 9, 2023 Author

blackghost1987 Dec 9, 2023

SergioBenitez Dec 9, 2023 Maintainer

darksylinc Dec 10, 2023 Author

darksylinc
Dec 8, 2023

Replies: 1 comment 4 replies

DavidSkrundz
Dec 9, 2023

darksylinc Dec 9, 2023
Author

SergioBenitez Dec 9, 2023
Maintainer

darksylinc Dec 10, 2023
Author