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

use the requested Host header in the proxied request #444

Closed
ahmadnassri opened this issue Aug 2, 2015 · 4 comments
Closed

use the requested Host header in the proxied request #444

ahmadnassri opened this issue Aug 2, 2015 · 4 comments
Assignees
Labels
Milestone

Comments

@ahmadnassri
Copy link
Contributor

When setting up Kong in-front of an API service that relies on the Host header for routing (e.g. Kong itself), Kong uses the target_url in the proxied request.

it should either:

  • have a flag to use the client-side Host header all the way through (perhaps this should be the default?)
  • allow the Host header to be set at the time of creation as an additional property of the API object.

alternatively the request-transformer plugin could be used here, however, currently attempting to overwrite the Host header with request-transformer does nothing. (see #445)

detailed example:
┌────────────────────┐
│      Consumer      │
└────────────────────┘
           │
           ▼
┌────────────────────┐
│GET / HTTP/1.1      │
│Accept: */*         │
│Host: mockbin.com   │
└────────────────────┘
           │             ┌─────────────────────────────────────────┐
           ▼             │{                                        │
┌────────────────────┐   │  "public_dns": "mockbin.com",           │
│        Kong        │───│  "target_url": "http://173.236.235.78/" │
└────────────────────┘   │}                                        │
           │             └─────────────────────────────────────────┘
           ▼
┌────────────────────┐
│GET / HTTP/1.1      │
│Accept: */*         │
│Host: 173.236.235.78│
└────────────────────┘
           │             ┌─────────────────────────────────────────┐
           ▼             │{                                        │
┌────────────────────┐   │  "public_dns": "mockbin.com",           │
│        Kong        │───│  "target_url": "http://mockbin.org/"    │
└────────────────────┘   │}                                        │
           │             └─────────────────────────────────────────┘
           ▼
┌────────────────────┐
│  API not found :(  │
└────────────────────┘

           x
┌────────────────────┐
│    mockbin.org     │
└────────────────────┘
@subnetmarco
Copy link
Member

I can easily fix this, but it may lead to some problems. I believe the reason we decided to change the Host header to reflect the target url's host, is because it created issues with the Virtual Host resolution: some servers that handle more than one host, use the Host header to determine the Virtual Host that should process the request.

We need to better test this. If we find out that it can cause problems, then this needs to be a flag when adding the API, like preserve_host = true | false.

@subnetmarco
Copy link
Member

Specifically, we need to understand if this is really required: https://github.com/Mashape/kong/blob/master/kong/resolver/access.lua#L179

The fix to this issue would be to comment that line, and add the following nginx directive before the proxy_pass instruction:

proxy_set_header Host $host;

@subnetmarco subnetmarco self-assigned this Aug 3, 2015
@subnetmarco subnetmarco added this to the 0.5.0 milestone Aug 3, 2015
@ahmadnassri
Copy link
Contributor Author

as mentioned, I believe both solutions are valid (in different scenarios) therefore, should be flag ... or a feature of request transform plugin

@subnetmarco
Copy link
Member

I have added the preserve_host flag (default false) when adding a new API.

ctranxuan pushed a commit to streamdataio/kong that referenced this issue Aug 25, 2015
Former-commit-id: f97f9385bc5effa6d92be5f4279f5b7cd7f9e8d4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants