Re: [jetty-dev] Modifying the client request after the TLS handshake is

[Ludovic Orban <lorban@xxxxxxxxxxx>]

This is an interesting problem, I don't know if the client API allows that so I'm going to discuss that with the team and come back to you.

In the meantime, if you're only interested in HTTP 1.1 (at least for now), you should still be able to modify the request headers onHeaders() by overriding this method in your SigAuthClientListener. That won't work in all cases, but it's worth a try.

--

Ludovic Orban / lorban@xxxxxxxxxxx

On Thu, Mar 7, 2024 at 12:06 PM Abel Luck via jetty-dev <jetty-dev@xxxxxxxxxxx> wrote:

Hello jetty devs!

I am a developer working on implementing proof-of-concepts of an
upcoming IETF standard, a new HTTP authentication scheme called
Signature auth [0], or sometimes referred to as "Unprompted Auth"
(because the client sends the authentication request unprompted by the
server).

To be clear, I'm not working on a patch-set that would be directly
submitted to Jetty. This is an earlier stage where we are just working
on getting a working implementation of the draft. Polishing it up into a
production ready patch would come later, and will likely look different
than my proof of concept.

I chose to implement my proof on concept with Jetty since it is one of
the most widely used web server in the java ecosystem, but I don't need
to sing the praises of Jetty to you.

There is now  a semi-working server implementation of this draft with
Jetty, and now I am trying to implement it on the client using Jetty's
client library.

My problem:

* I need to be able to modify the request headers *after* the TLS
handshake is complete
* The `onBegin` listener is the last chance to modify the request
* ..but the `onBegin` listener fires before the TLS handshake is complete

You can see this in my small demo [1].

I've been banging my head against Jetty internals for a few days now and
would appreciate some ideas from you all.

Things I've tired:

* set connect blocking on the connector. Result: doesn't have an effect
* setting a single-threaded thread pool executor. Result: hangs jetty
when it starts.
* I'm trying to find the right layer of abstraction to hook in with a
custom implementation of HttpConnectionOverHTTP, etc, to delay the
request, but without success so far.

I am *ok* with a reflection-based solution or something else equally as
hacky, once again this is just a proof-of-concept.

Cheers,

~abel

[0]:
https://www.ietf.org/archive/id/draft-ietf-httpbis-unprompted-auth-06.html
[1]: https://gist.github.com/abeluck/2cde182eecced0f1a61ee77085124a22
_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-dev