Bad format in URL always gives "URIError: Failed to decode param..."


#1

Hello,

Bad format of URI always gives “URIError”, it doesn’t matter how I handle the error with node or express.

For example I tried the standard

app.use(function (err, req, res, next) {
console.error(err.stack) 
res.status(500).send('Bad Request!')
})

and in a local node server it gives Bad Request, but in glitch always

URIError: Failed to decode param

#2

Can you show us how you are triggering the URIError so we can see how it fits in with your error route you showed us? I thought I had an idea, but probably need further details to confirm.

For example, is this from an incoming request you are sending the server, or are you decoding a URI somewhere from an input from a user? Or something else entirely perhaps?

Thanks.


#3

It is from a request sent to the server (http://myhost.com/myrequest)

The code in Express is the following:

app.get("/:date",function(req,res){
         console.log(req.params.date)
})

app.use(function (err, req, res, next) {
      console.log('hit error handler');
      res.sendStatus(err.status || 500);
})

In my local node server if my request brings with a % for example, the response is Bad Request.
In glitch exactly the same code gives URIError: Failed to decode param


#4

% has a special meaning in a URL - it means it’s URL encoded. That error could be coming from your browser or any part of glitch that’s between your browser and your project. Since the URL is invalid, the request isn’t getting as far as your Glitch project. The question is, do you really want to send your project an invalid URL? If so, why?

This isn’t really what Express error handlers are for. Express will already return a 404 for requests that don’t match an existing route. The error handler is called when there’s an exception in the code handling one of your routes. More on Express error handling: http://expressjs.com/en/guide/error-handling.html


#5

No, I don’t want to send a invalid URL, but the user could.

So, if the user send

https:myhost.com/December%2015,%202015 

response in both local server and glitch December 15, 2015

but if the user send

https:myhost.com/December% 

response in local node server Bad Request ,
but in glitch URIError: Failed to decode param ‘/December%2015,%’

So, it seems that with the same code the malformat URI reach a local node server and gives the expected response ‘Bad Request’, but in glitch the malformat URI gives a URI error in the browser not having the chance to reach the server for handling the error


#6

I think what @Tim is suggesting is that the invalid URL fails at (what I suppose) is the frontend load-balancer/proxy or equivalent - which is the thing that examines every single request coming in to Glitch’s platform and proxies it through to the correct project’s server.

However, in the case of an invalid URL, instead of proxying it to a project, it is dealt with right there and then and fails at the load-balancer stage. It doesn’t reach your app at all! It is Glitch’s own server responding to the request with a URIError and not yours. Hence this explains the discrepancy between what you’re seeing locally (which is your app responding) and when running on Glitch (which is their load-balancer/proxy responding, and not your app at all).

Does that make sense? Let us know if you need any more clarification, or indeed if it still doesn’t make sense with what you’re seeing.


#7

Yes, it makes sense.

I supposed that it was something in the client side checking the URI and if it is malformat no allowing to go further (to the server).

Anyway I put some line of the error stack:

URIError: Failed to decode param '/December%2015,%'
at decodeURIComponent (native)
at decode_param (/opt/glitch/proxy/node_modules/express/lib/router/layer.js:172:12)
at Layer.match (/opt/glitch/proxy/node_modules/express/lib/router/layer.js:123:27)
at matchLayer (/opt/glitch/proxy/node_modules/express/lib/router/index.js:574:18)
at next (/opt/glitch/proxy/node_modules/express/lib/router/index.js:220:15)
at expressInit (/opt/glitch/proxy/node_modules/express/lib/middleware/init.js:40:5)
at Layer.handle [as handle_request] (/opt/glitch/proxy/node_modules/express/lib/router/layer.js:95:5)

As you said, it looks like something in the proxy.