Query parameter ordering not guaranteed to stay the same

[cowwoc]

Some use-cases (e.g. https://github.com/binance-exchange/binance-official-api-docs/blob/master/rest-api.md#signed-trade-and-user_data-endpoint-security) requires one to be able to look up the query parameter string and request body before actually sending out the request. In the aforementioned case, we are supposed to use these values to generate a hash where ordering maters.

Looking at the Javadoc, there doesn't seem to be any explicit guarantee that the constructed URI will maintain the ordering of the query parameters. Specifically, nothing guarantees that getUri() will return the same ordering every time, nor that ordering will be kept when I add a new query parameter (e.g. signature). I am worried that a=1&b=2&c=3 could turn into b=2&c=3&a=1&signature=<hash>.

Is there a reasonably safe way for the specification to support this use-case?

[mkarg]

Is there a RFC that guarantees order of parameters?

[cowwoc]

@mkarg The only guarantee that binance seems to ask for is that the signature corresponds to the order of parameters that the client sends (what the server does with it is another story). Are you saying that if there are intermediate gateways they might reorder the parameters?

[chkal]

I think @mkarg is thinking about the HTTP or some other RFC and what they write about query parameter ordering...

[cowwoc]

@chkal I could not find any such guarantee either but the API author is resisting making any changes.

I explained that the current API makes it "impossible to safely sign requests using HTTP parameters" and he replied:

This isn't true. This would only be true if, after making the request, any intermediate servers the request passed through re-arranged the query parameters. I don't know of any intermediate router/proxy/CDN/etc. that does this. If you send blah.asdf/api?one=1&two=2&three=3&sig=fooBarBaz, intermediate servers aren't going to shuffle one, two, three, and/or sig around. I haven't looked at the RFCs in detail but I imagine there's something that would say when acting as an intermediary it's illegal to modify the URI and body.

I've asked for him to join this discussion directly but I'm not sure whether that will happen. It would be nice to find some specific examples of proxies/gateways that reorder query parameters as a counter-example.

UPDATE: Just got a word back from the API authors. They won't be making any changes (probably for backwards-compatibility reasons) and aren't interested in further discussion :(

[mkarg]

As long as there is no RFC guaranteeing such a preserve-of-order, any intermediate party (like proxies, routers, gateways, etc.) is allows to reorder as wanted. So it makes no sense to enforce something in the backend only.

It makes no sense to collect a proof for actual reordering. This is an API Specification project, so we have to think revers: We need a proof that no party might reorder.

[mkarg]

@cowwoc Well... does "the aren't interested in further discussion" mean that I can close this issue now?

[cowwoc]

@cowwoc Well... does "the aren't interested in further discussion" mean that I can close this issue now?

Sadly, yes. Thanks for the clarification.