Documentation: proxied request must be readable when handed over to the proxy

Open
#124 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
java
Domain
api, backend

Research direction

Start by reproducing the failure with vertx-http-proxy 4.5.14 and inspect ProxyRequest.reverseProxy, ProxiedRequest, and the HttpServerRequest ended-state handling shown in the stack trace. Determine the expected behavior for requests that are already ended versus still readable. Done means the behavior is handled consistently or the required precondition is documented, with a regression test covering the reported timing case.

Written by the indexing model from the issue text.

Description

documentation enhancement help wanted

Hi there,

I am building a reverse proxy using vertx-http-proxy (4.5.14) - Java 17 - Linux . In some cases the origin is selected after querying a DB that has some kind of routing information using a key provided in the request.

For building the proxied request I am using

static ProxyRequest reverseProxy(HttpServerRequest proxiedRequest)

In some cases this method throws
java.lang.IllegalStateException: Request has already been read
at io.vertx.core.http.impl.Http2ServerRequest.checkEnded(Http2ServerRequest.java:205) ~[vertx-core-4.5.14.jar:4.5.14]
at io.vertx.core.http.impl.Http2ServerRequest.pause(Http2ServerRequest.java:257) ~[vertx-core-4.5.14.jar:4.5.14]
at io.vertx.httpproxy.ProxyRequest.reverseProxy(ProxyRequest.java:41) ~[vertx-http-proxy-4.5.14.jar:4.5.14]
at com.chevaris.plt.proxy.router.Proxy.sendProxyRequest(Proxy.java:260) ~[classes/:?]
at com.chevaris.plt.proxy.router.Proxy.lambda$13(Proxy.java:243) ~[classes/:?]
at com.chevaris.plt.proxy.router.VertxBulkhead.executeFuture(VertxBulkhead.java:30) ~[classes/:?]
at com.chevaris.plt.proxy.router.Proxy.lambda$11(Proxy.java:233) ~[classes/:?]
at io.vertx.core.impl.future.Composition.onSuccess(Composition.java:38) ~[vertx-core-4.5.14.jar:4.5.14]
at io.vertx.core.impl.future.FutureBase.emitSuccess(FutureBase.java:66) ~[vertx-core-4.5.14.jar:4.5.14]
at io.vertx.core.impl.future.FutureImpl.tryComplete(FutureImpl.java:259) ~[vertx-core-4.5.14.jar:4.5.14]
at io.vertx.core.impl.future.Composition$1.onSuccess(Composition.java:62) ~[vertx-core-4.5.14.jar:4.5.14]
at io.vertx.core.impl.future.FutureBase.emitSuccess(FutureBase.java:66) ~[vertx-core-4.5.14.jar:4.5.14]
at io.vertx.core.impl.future.SucceededFuture.addListener(SucceededFuture.java:88) ~[vertx-core-4.5.14.jar:4.5.14]
at io.vertx.core.impl.future.Composition.onSuccess(Composition.java:43) ~[vertx-core-4.5.14.jar:4.5.14]
at io.vertx.core.impl.future.FutureBase.lambda$emitSuccess$0(FutureBase.java:60) ~[vertx-core-4.5.14.jar:4.5.14]
at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173) ~[netty-common-4.1.118.Final.jar:4.1.118.Final]
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166) ~[netty-common-4.1.118.Final.jar:4.1.118.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472) ~[netty-common-4.1.118.Final.jar:4.1.118.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569) ~[netty-transport-4.1.118.Final.jar:4.1.118.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:998) ~[netty-common-4.1.118.Final.jar:4.1.118.Final]
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.118.Final.jar:4.1.118.Final]
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) ~[netty-common-4.1.118.Final.jar:4.1.118.Final]
at java.lang.Thread.run(Thread.java:840) ~[?:?]

Checking the code I have seen that ProxyRequest and ProxiedRequest relies on that fact that original HttpServerRequest to build the ProxiedRequest instance is NOT ended (that could NOT be always the case, depending on timing/business logic). The issue call be avoided creating the proxiedrequest at the beginning of the flow when the original request is NOT ended (at least should be documented if that is expected in my view), BUT I think the code should be more flexible checking if the request is ended or NOT in order to do the right thing in both cases.

Regards,

Chevaris

Dominant language
Java
Stars
68
Forks
37
Avg merge
8m
Merged PRs (30d)
1

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from eclipse-vertx/vertx-http-proxy

All issues in eclipse-vertx/vertx-http-proxy

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.