Getting empty buffer in proxyResData when the http status is 304

[icaroponce]

Hello there,

Recently I've got some troubles using this module.

I'm trying something like that:

app.get('/users/a', proxy(serviceUrl, {
    proxyReqPathResolver: function(req) {
      return parseurl(req).path.replace('/a', '/b');
    },
    userResDecorator: function(proxyRes, proxyResData, userReq, userRes) {
      const items = JSON.parse(proxyResData.toString('utf-8')).data;
      ...
      return JSON.stringify(modifiedItems);
    }
  }));

When I do the first request from my client, which has no custom headers set, I get a 200 HTTP response code, everything's as expected. But, when I do the same request again, e.g. refreshing the page, and I gettting a 304 status code, the variable proxyResData is an empty Buffer ( which shouldn't be happening in this case ), hence my app crashs due to the JSON parse error.

Weirdly it only happens when I get a 304 status code as response.
I could "solve" it using a workaround to avoid the 304 so far: setting the param cache-control to no- cache in the request headers on my client request, however I wouldn't like to do this.

I'm looking forward to hear from you if I'm doing something wrongly or if any of you experienced this same situation.

Thanks.

[monkpow]

If I'm reading this right, you're doing:

user request => express-http-proxy => proxyServer

on first request, proxyServer returns 200 with data, and express-http-proxy returns 200 with data
on second request, proxyServer returns 304, not modified, with no document, and express-http-proxy returns 304, not modified and with an empty Buffer.

Did i describe this correctly?

This is how I expect it to behave, but I'm interested in hearing more about what you expect to happen? Is it the empty Buffer (rather than another 'falsey' value) that's throwing your case off?\

Edit: OK, I think you're saying => on 304, i shouldn't be getting an empty buffer for proxyRes. It looks like you're expecting a string in your code.

[icaroponce]

Yes, you did.

I wasn't expecting it to be an empty document. Since the service, which I'm proxying to, returns a JSON document, and I need to do some processing whit this parsed json document on the userResDecorator before send it back to the client.

As I'm getting a 304 not modified, and it's an empty document, my app's crashing every time I refresh the page for example, since it can't parse to object this empty document returned, which should be a json, as in the 200 ok.

You mentioned it's behaving as expected, can you give me some link where I can understand the reason?

As I've mentioned before, I'm setting a cache-control to avoid the 304 and not break the app so far.
I'm interested to hear what I should do in this situation if it's behaving exactly as expected.

[monkpow]

Well, the issue (as I see it) is that here

 const items = JSON.parse(proxyResData.toString('utf-8')).data;

you're expecting proxyResData to be a parseable buffer with a data attribute.

And you would instead first need to verify there's a document to parse and find attributes on. something like

(proxyResData && proxyResData.toString('utf-8') && proxyResData.toString('utf-8')).data)

You might be assuming that your proxy server is returning JSON on the second request, but it is instead responding 304, nothing changed. In this case it doesn't send a document back (your JSON), its just saying, the one you already have is good, use that one.

There are no near-term plans to have this library cache responses on behalf of the proxy server (although this has been requested), so that express-http-proxy could response with JSON when the proxy server does not, for instance.

Adding the cache-control as you have done tells your proxy server not to answer 304, but instead give the JSON each time, which express-http-proxy then passes back to you.

I've written a little fix that would SKIP handling the userResDecorator on body-less response types, but I'm not sure that's what you're asking for here.

It sounds like you'd like the express-http-proxy library to keep track of the JSON from the first response, and add it to the second response if your proxy returns 304? I don't think we're going to do this any time soon; we are considering maybe down the road supporting some hooks to support pluggable caching, but that's not a high priority at this time.

So, first, I hope I'm understanding the issue correctly.

I believe the options you have are:

1. cache-control (this one feels right to me)
2. adjust your proxy server so it doesn't respond with 304

[icaroponce]

No, it's not exactly what I'm asking for, but the change in the docs may be very useful ( since I was using the decorator exactly as its usage was described in the docs ) to reference this situation as you did in your last commits.

As in my use case, although the response 304 not modified, received from the proxy server indicates that nothing has changed on the first server, I might change the data on the decorator every time a client hits the endpoint, so skipping the decorator for an empty buffer is not what I'd like to do in this case.

Yes, you understand it well, hope I could briefly explain my use case well too.

In this case I'll keep on using the cache-control in the request headers to get it working. Hope you guys are gonna find a good pluggable cache module to integrate with this module for this kind of use cases in a soon future.

Thanks for supporting.

[monkpow]

hmm. This is quite an unusual use case. It no longer sounds like you are trying to cache a response, but instead that if the user gets a 304, you might give them an arbitrary response that might be different for each request.

I'm curious if you have looked at maybeSkipToNext. This would allow you to call next() if you get 304 back, and let a subsequent handler in your app handle a decorated response.

[icaroponce]

Not exactly. It's not an arbitrary response. The response returned by the proxy to the client is based on the proxied server response, so, the best option for me would be cache the response and use it when we get a 304 from the proxied server.

In my use case, I'm using this module to implement an API Gateway in a microservices architecture.
So, one of the API gateway capabilities is that it can be used as an aggregator, in this case, my api gateway needs to do some kind of "JOIN" at code-level. It gathers data from different microservices, and in one of these situations, it needs to consume resources from a service A, and then send these resources to a service B to get the final response. If the server A sends back a 304, the resources from the service B won't be retrieved, and the gateway will crash, As I've showed in the code above, on my previous comment.

So, if we cache have an option to cache the response, when a service A returns a 304 the gateway could go ahead and send the cached response to the service B, and everything would work out well.

I'm still using the cache-control in the request header, and it's working well so far.

The maybeSkipToNext method is very useful in another use case, when the service A returns an error for example, than I'd like to skip the decorator and send the error to error handler in the next variable.