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

feat(proxy) add route.request|response_buffering #6057

Merged
merged 2 commits into from Sep 21, 2020
Merged

Conversation

bungle
Copy link
Member

@bungle bungle commented Jun 26, 2020

Summary

Request Buffering

By default Kong does buffer the request. This is not ideal when proxying bigger payloads with HTTP 1.1 chunked encoding.

This PR adds a new property to route entity:

request_buffering = <true/false>

By default that is true (which is the same as before). Users can now turn the request buffering off by route-by-route manner by setting route.request_buffering=false.

Response Buffering

By default Kong does buffer the response. This is not ideal when upstream is sending payloads with HTTP 1.1 chunked encoding.

This PR adds a new property to route entity:

response_buffering = <true/false>

By default that is true (which is the same as before). Users can now turn off the response buffering on route-by-route manner by setting route.response_buffering=false.

@bungle bungle added the pr/wip A work in progress PR opened to receive feedback label Jun 26, 2020
@bungle bungle force-pushed the feat/unbuffered branch 5 times, most recently from e083bb8 to 674a1d7 Compare June 26, 2020 10:16
@bungle bungle added the pr/discussion This PR is being debated. Probably just a few details. label Jun 26, 2020
@bungle
Copy link
Member Author

bungle commented Jun 26, 2020

So the obvious discussion is: do we want this?

@bungle bungle force-pushed the feat/unbuffered branch 2 times, most recently from 03ad1c9 to d440d3b Compare July 1, 2020 20:02
@bungle bungle changed the title feat(proxy) add service.request_buffering feat(proxy) add service.request|response_buffering Jul 1, 2020
@gmazerogers-zuora
Copy link

@bungle These changes look great. I think adding the property to the route instead of the service is a better fit IMO. Otherwise, users would need to figure out a workaround if they only wanted to modify one route on a service.

@bungle bungle force-pushed the feat/unbuffered branch 3 times, most recently from 4e5f59d to ba40692 Compare September 9, 2020 18:45
@bungle bungle changed the title feat(proxy) add service.request|response_buffering feat(proxy) add route.request|response_buffering Sep 9, 2020
@bungle bungle added this to the 2.2.0 milestone Sep 9, 2020
@bungle bungle force-pushed the feat/unbuffered branch 4 times, most recently from bb8d4c0 to e4cecfa Compare September 11, 2020 13:50
@bungle bungle removed the pr/discussion This PR is being debated. Probably just a few details. label Sep 11, 2020
### Summary

By default Kong does buffer the request. This is not ideal when proxying
bigger payloads with HTTP 1.1 chunked encoding.

This commit adds a new property to route entity:
```
request_buffering = <true/false>
```

By default that is `true` (which is the same as before). Users can now
turn off the request buffering on route-by-route manner by setting
`route.request_buffering=false`.
By default Kong does buffer the response. This is not ideal when upstream
is sending payloads with HTTP 1.1 chunked encoding.

This commit adds a new property to route entity:
```
response_buffering = <true/false>
```

By default that is `true` (which is the same as before). Users can now
turn off the response buffering on route-by-route manner by setting
`route.response_buffering=false`.
@bungle bungle added pr/please review and removed pr/wip A work in progress PR opened to receive feedback labels Sep 14, 2020
@bungle bungle marked this pull request as ready for review September 14, 2020 20:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants