calling a nodejs express REST service with & into url

[Adrian Albu]

having built an express REST api got a problem when one of the clients is calling one service with encoding the & to &

I do not know how to modify all the request object's properties before is routed.

I tried in a middleware to modify the req.query object but the req.query keys itself are "corrupted":

ex: 'amp;paramname' because express it is splitting it at & from &

Call ex.: https://localhost:8080/rs?p1=v1&p2=v2&

then req.query is:

{ p1: 'v1',
  'amp;p2': 'v2',
  'amp;p3': ... }

app.js:

var express    = require('express');        // call express
var app = module.exports = express();      
var bodyParser = require('body-parser');
var validator = require('express-validator');
var cors = require('cors');




app.use( bodyParser.json() );
app.use( bodyParser.urlencoded({ extended: true }) );
app.use( validator() );
app.use( cors() );




// START THE SERVER
// =============================================================================
if(!module.parent){ app.listen(config.port); }


// REGISTER OUR ROUTES -------------------------------
app.use('/rs', require('./routes/rsRoutes'));

[Ryan Schmidt]

On Mar 31, 2016, at 9:12 AM, Adrian Albu wrote:

> having built an express REST api got a problem when one of the clients is calling one service with encoding the & to &

Fix the client to not do that.

[Adrian Albu]

That is not possible since I have no responsibility on that application, belongs to another company and so on...

I know is crap they encode the url so or something but... 

[Zlatko]

On Friday, April 1, 2016 at 8:20:04 AM UTC+2, Adrian Albu wrote:

That is not possible since I have no responsibility on that application, belongs to another company and so on...

I know is crap they encode the url so or something but... 

It's not crap. They're simply not following your API correctly.

Your API:

p1: string

p2: string

Valid call: ?p1=v1&p2=v2.

From your example (https://localhost:8080/rs?p1=v1&p2=v2&), they only set p1 parameter, to "v1". They also set an "amp;p2" parameter to "v2", and finally, they set an undefined "amp" parameter. Tell the client to also set the v2 parameter, and your call will work.

[Ryan Schmidt]

On Apr 1, 2016, at 1:15 AM, Adrian Albu wrote:

> vineri, 1 aprilie 2016, 06:14:35 UTC+2, ryandesign a scris:
>
>> On Mar 31, 2016, at 9:12 AM, Adrian Albu wrote:
>>
>> > having built an express REST api got a problem when one of the clients is calling one service with encoding the & to &
>>
>> Fix the client to not do that.
>
> That is not possible since I have no responsibility on that application, belongs to another company and so on...
>
> I know is crap they encode the url so or something but...

How can they write a client that doesn't work because it sends nonstandard requests, then ask you to change the server to work around their broken client? What sense does that make?

I would imagine the reason why you're having difficulty making express handle these requests is that no sane client should be sending requests like that.

It's not your responsibility, it's theirs.

[Adrian Albu]

I know you are right and in the end will tell them not to do this shit.

I was anyway curious if there is a solution still on my side...

Thanks for the response.

[Adrian Albu]

Yes but the problem is that they were using an old api that somehow worked with this type of call and my new api has new REST calls but should work also with the old ws type of calls, so when I did it I had example calls and didn't see they also can use some with & instead of &.

Old api was in php and they didn't have this problem, it seems.

To tell them now they have to change the way they did some calls is a bit hard because of political shit.

[Adrian Albu]

Thanks guys, I guess it is clear that the call is bad and the client must change.

[Zlatko]

On Monday, April 4, 2016 at 3:11:15 PM UTC+2, Adrian Albu wrote:

Yes but the problem is that they were using an old api that somehow worked with this type of call and my new api has new REST calls but should work also with the old ws type of calls, so when I did it I had example calls and didn't see they also can use some with & instead of &.

Old api was in php and they didn't have this problem, it seems.

To tell them now they have to change the way they did some calls is a bit hard because of political shit.

Yes, I understand this part, it can be. But what did the PHP API look like - you do have access to that? Go see how they parsed the url.

Then I'd advise something like this (that's what I would do):

- if the PHP API does something weird: 

1. Copy the weird behavior in your new API - add it to a simple middleware that fixes URL params.

2. Place your new, proper route under `/api/v2/call`

3. Put your middleware and then the new API endpoint under `/api/v1/call`.

(Or some variation of that).

Then you can tell them - "hey, our old API was defective in this way, sorry you had to use that behavior. It's now under legacy endpoint there, but you can use proper calls here, we'll be developing new stuff under there in future."

If PHP API didn't do weird stuff and if it's simply weird in itself, then just write a parser for the req.url as a middleware which extracts your needed params. I'd still keep the legacy/v2 approach though.