8000 EOF for DPE requests with extProc response headers sending enabled · Issue #10402 · solo-io/gloo · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

EOF for DPE requests with extProc response headers sending enabled #10402

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.

Sign up for GitHub

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

Jump to bottom
Closed
huzlak opened this issue Nov 25, 2024 · 3 comments
Closed

EOF for DPE requests with extProc response headers sending enabled #10402

huzlak opened this issue Nov 25, 2024 · 3 comments
Assignees
@nfuden
Labels
bug Something isn't working Prioritized Indicating issue prioritized to be worked on in RFE stream Zendesk

Comments

@huzlak
Copy link
huzlak commented Nov 25, 2024

Gloo Edge Product

Enterprise

Gloo Edge Version

v1.17.4

Kubernetes Version

v1.29.2

Describe the bug

When responseHeaderMode: SEND is set in extProc filter and client sends a request with unsupported protocol, no response is returned to client.

Expected Behavior

The same DPE to be sent to client as without response header sending enabled

Steps to reproduce the bug

  1. Complete https://docs.solo.io/gloo-edge/latest/guides/traffic_management/extproc/header-manipulation/
  2. Run request with unsupported protocol and see the response received
$ curl --http1.0 $(glooctl proxy url --name gateway-proxy)/get -v
*   Trying 172.18.9.1:80...
* Connected to 172.18.9.1 (172.18.9.1) port 80
> GET /get HTTP/1.0
> Host: 172.18.9.1
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/1.1 426 Upgrade Required
< content-length: 16
< content-type: text/plain
< date: Mon, 25 Nov 2024 08:28:58 GMT
< server: envoy
< connection: close
< 
* Closing connection
Upgrade Required
  1. Edit settings and set responseHeaderMode: SEND in extProc configuration
  2. Run the same request and observe the difference
curl --http1.0 $(glooctl proxy url --name gateway-proxy)/get -v
*   Trying 172.18.9.1:80...
* Connected to 172.18.9.1 (172.18.9.1) port 80
> GET /get HTTP/1.0
> Host: 172.18.9.1
> User-Agent: curl/8.5.0
> Accept: */*
> 
* Empty reply from server
* Closing connection
curl: (52) Empty reply from server

Additional Environment Detail

No response

Additional Context

No response
@soloio-bot
Copy link

Zendesk ticket #4951 has been linked to this issue.

@Jimmmz Jimmmz added bug Something isn't working Prioritized Indicating issue prioritized to be worked on in RFE stream labels Nov 26, 2024
@nfuden
Copy link
nfuden commented Nov 26, 2024

This looks like the extproc server itself is unable to handle the response and envoy gets an eof from extproc. I think the easiest way to hit a reproducer on this is to spin this up with the test.
Based of what we see there then the next step is to see about message_timeout and failure_mode in extproc filter configuration

ymesika pushed a commit that referenced this issue Apr 23, 2025
@timflannagan
README: Fix broken links (#10402)
9e9d1ea 
Signed-off-by: timflannagan <timflannagan@gmail.com>
@birkland
Copy link

zendesk ticket marked as solved, forgot to close

@birkland birkland closed this as not planned Won't fix, can't repro, duplicate, stale May 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@nfuden nfuden

Labels
bug Something isn't working Prioritized Indicating issue prioritized to be worked on in RFE stream Zendesk
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@birkland @Jimmmz @huzlak @soloio-bot @nfuden
0