Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reroute sending empty Content-Type which causes Bad request #464

Closed
vasicvuk opened this issue Jul 11, 2018 · 16 comments
Closed

Reroute sending empty Content-Type which causes Bad request #464

vasicvuk opened this issue Jul 11, 2018 · 16 comments
Labels
bug Identified as a potential bug good first issue Should be pretty easy to do help wanted Not actively being worked on. If you plan to contribute, please drop a note. merged Issue has been merged to dev and is waiting for the next release small effort Likely less than a day of development effort.

Comments

@vasicvuk
Copy link
Contributor

vasicvuk commented Jul 11, 2018

Expected Behavior / New Feature

When sending Http get request from ocelot to downstream. Content-Type should not be sent.

Actual Behavior / Motivation for New Feautre

Currently there is an empty Content-Type header sent. Also Content-Length: 0 is extra too. This causes for most APIs made in Java to give 400 Bad request since they don't have formatter for Content-Type empty string. Sample:

image

Steps to Reproduce the Problem

  1. Install Fidler
  2. Trace reroute to downstream
  3. See empty content type and length in request headers

Specifications

  • Version: 8.0.0
  • Platform: Windows 10 x64
  • Subsystem: .Net core 2.1
@TomPallister TomPallister added bug Identified as a potential bug help wanted Not actively being worked on. If you plan to contribute, please drop a note. good first issue Should be pretty easy to do small effort Likely less than a day of development effort. labels Jul 12, 2018
@TomPallister
Copy link
Member

@vasicvuk thanks for your interest in the project! Mmmmmmmm I didn't even realise I'm adding these on...I think the issue is in RequestMapper.cs but not 100%. It looks like the Content-Type header is added there but I cannot find where the Content-Length header is being added.

This should be pretty easy to fix and will just need some debugging to work it out.

@TomPallister
Copy link
Member

Ill try get it fixed asap

@vasicvuk
Copy link
Contributor Author

@TomPallister thank you for quick response. I will try to debug it too in order to see where the problem is.

@vasicvuk
Copy link
Contributor Author

Seems like HttpRequest by default has System.IO.Stream+NullStream not null. So the headers are added anyway since request.Body is never null.

if (request.Body == null)

Still not sure how Content-Length is added but maybe it is added by default if Content-Type is provided.

Here is the little test i made to see what is value of body:

           DefaultHttpRequest defaultHttp = new DefaultHttpRequest(CreateHttpContext())
            {
                Method = HttpMethods.Get,
                Protocol = "https",
                Host = new HostString("samplehost"),
                Path = "/api/cockpit/plugin/asseco/static/app/plugin.js",
                ContentType = " "
            };
            if(defaultHttp.Body == null) {
                Console.WriteLine("Body is null");
            } else {
                Console.WriteLine("Body is not null " + defaultHttp.Body);
            }

This test returns: Body is not null System.IO.Stream+NullStream

@TomPallister
Copy link
Member

@vasicvuk yep as expected that is the problem area! :)

@mciureanu
Copy link

The same thing happens when running Ocelot and the API in the same process with aspnet core 2.1 Ocelot adds this empty header causing the API to fail. I have added a middleware to remove this empty header to avoid this problem

@TomPallister
Copy link
Member

@vasicvuk sorry I have not fixed this yet, I have been away for a few days! Will get on it ASAP.

@TomPallister
Copy link
Member

@vasicvuk what are you hosting Ocelot with e.g. Linux / Windows? Is there anything in front of Kestrel e.g. IIS / nginx?

When I debug Ocelot I Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.FrameRequestStream as the type for a stream when I curl with GET so no body.

I think there is might be some .net core magic here to contend with!

@TomPallister
Copy link
Member

There are also ConentType and ContentLength properties on the request object...I guess I could use them to say if they don't exist then definitely don't add any content.

@vasicvuk
Copy link
Contributor Author

vasicvuk commented Jul 18, 2018

I use ASP.Net Core 2.1 running it with IIS through Visual Studio 2017 Community on Windows 10 64 bit.

@TomPallister
Copy link
Member

Ok cool, I will keep looking!

@vasicvuk
Copy link
Contributor Author

I guess that you can trim it when Content-Length is 0 but it would be nice to know what is causing an issue

@TomPallister
Copy link
Member

@vasicvuk I think NullStream is an internal type so you cant check or instantiate it. I also think it is only set when you instantiate DefaultHttpRequest...not when you receive an actual HttpRequest!

TomPallister pushed a commit that referenced this issue Jul 18, 2018
…pe and content length headers, .net will automatically try and add these headers in a few circumstances but this solves the 464 issue
@TomPallister TomPallister mentioned this issue Jul 18, 2018
TomPallister added a commit that referenced this issue Jul 20, 2018
* #464 added code to request mapper to not automatically add content type and content length headers, .net will automatically try and add these headers in a few circumstances but this solves the 464 issue

* #464 use seek instead of read on body check for websockets tests

* #464 ran out of inodes on linux, looks like reloadonchange causes this
@TomPallister TomPallister added the merged Issue has been merged to dev and is waiting for the next release label Jul 20, 2018
@TomPallister TomPallister reopened this Jul 20, 2018
@TomPallister
Copy link
Member

Released in version 8.0.1

@vasicvuk
Copy link
Contributor Author

Confirming that everything works now! 👍

@TomPallister
Copy link
Member

sweet

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Identified as a potential bug good first issue Should be pretty easy to do help wanted Not actively being worked on. If you plan to contribute, please drop a note. merged Issue has been merged to dev and is waiting for the next release small effort Likely less than a day of development effort.
Projects
None yet
Development

No branches or pull requests

3 participants