raman-m
commented
1 year ago Hi Mortana! Thanks for the interesting question!
- ASP.NET Core 6.0
- Ocelot 18.0
Could you upgrade your solution to v19 for .NET 7 please?
When we try to send the same call to the individual microservice directly, we receive a successful response, so I'm thinking Ocelot is not adhering to the limits for some reason, when replaying the HTTP request to a downstream service.
Is that possible?
Everything is possible! 🤣 What is the technical stack of your downstream service? .NET or other technology?
I guess Ocelot as a ASP.NET API app follows and uses a standard settings for HttpClient and HttpRequest to setup HTTP headers for .NET framework.
As far as I know Ocelot does not limit header values, so it uses standard limits for HttpRequest.
We have configured Kestrel both on our gateway microservice and downstream services to accept header sizes up to 64Kb.
Please, show your solution and/or at least configuration code! We need to verify this setup.
However, we notice that, we are able to enter middleware in our gateway, but the moment we run the ocelot middleware, we receive a 400 headers too large.
Please, provide complete call stack information, and error message for sure!
Finally,
Is this a bug or feature issue? Do you have a draft solution?
Expected Behavior / New Feature
We have configured Kestrel both on our gateway microservice and downstream services to accept header sizes up to 64Kb. We should be able to send our GET request which contains a large continuation token, to these downstream services. However, we notice that, we are able to enter middleware in our gateway, but the moment we run the ocelot middleware, we receive a 400 headers too large. When we try to send the same call to the individual microservice directly, we receive a successful response, so I'm thinking Ocelot is not adhering to the limits for some reason, when replaying the HTTP request to a downstream service.
Is that possible?
Some information: