ARROW-10467: [FlightRPC][Java] Add the ability to pass arbitrary client headers.#8572
ARROW-10467: [FlightRPC][Java] Add the ability to pass arbitrary client headers.#8572kylepbit wants to merge 4 commits intoapache:masterfrom
Conversation
client properties.
|
What do you think about instead exposing headers as key-value metadata directly (on the sending side with a CallOption, on the receiving side via CallContext)? You could even still implement the server side like you've done here, with a standard middleware that can be configured. |
|
Ah, I see you want some keys that wouldn't necessarily be valid headers. |
|
Just stepping back for some context - what's the use case you have in mind for this? |
|
The intent is to be able to provide preferences to requests that would not be part of the actual action. Ex context to run the action in, etc. |
|
Ok. I think it'd make more sense to implement better support for headers in general, rather than have an interface to a single hardcoded header in Flight - anything higher-level (such as encoding an options map) can then be implemented in the application. Does that sound reasonable? |
|
Yes - do you have suggestions as to how you think that would be best done? Perhaps a CallOption to specify a header and give it a key and value where the value is serializable, and have a method that serializes the value that can be overridden if people wish to specialize? The server could register a set of headers that it would like to receive. |
| /** | ||
| * Interface for server side property handling. | ||
| */ | ||
| public interface ServerHeaderHandler extends Consumer<CallHeaders> { |
There was a problem hiding this comment.
Should we add a unit test that demonstrate a sample usage for this handler?
There was a problem hiding this comment.
| /** | ||
| * Middleware that's used to extract and pass properties to the server during requests. | ||
| */ | ||
| public class ServerHeaderMiddleware implements FlightServerMiddleware { |
There was a problem hiding this comment.
Can we rename ServerHeaderMiddleware to ServerPropertyMiddleware? The current name is a bit too generic.
There was a problem hiding this comment.
I think the name is appropriate given that this is intended to handle all headers for calls, which could be considered properties depending on the FlightServer implementation, but not necessarily.
| /** | ||
| * Interface for server side property handling. | ||
| */ | ||
| public interface ServerHeaderHandler extends Consumer<CallHeaders> { |
There was a problem hiding this comment.
Can we rename ServerHeaderHandler to ServerPropertyHandler? Like ServerHeaderMiddleware, the current name is a too generic.
There was a problem hiding this comment.
I agree with @tifflhl's suggestion the name is too generic, would something like ServerPropertyHeaderHandler and ClientPropertyHeaderHandler be more appropriate similar to ClientBearerHeaderHandler.
There was a problem hiding this comment.
This is not specific to properties - it's generally for handling all headers so I think the name fits.
| public interface FlightConstants { | ||
|
|
||
| String SERVICE = "arrow.flight.protocol.FlightService"; | ||
| String PROPERTY_HEADER = "Arrow-Properties"; |
There was a problem hiding this comment.
Let's rename this to something more specific (HEADERS_KEY?) and make it an instance of FlightServerMiddleware.Key. Let's also change the constant to something that's more clearly namespaced under arrow, e.g. "org.apache.arrow.flight.ServerHeaderHandler".
| /** | ||
| * Interface for server side property handling. | ||
| */ | ||
| public interface ServerHeaderHandler extends Consumer<CallHeaders> { |
There was a problem hiding this comment.
This interface confuses me, as it seems within an RPC handler, there's no way to get the headers associated with that particular call.
There was a problem hiding this comment.
Not sure I understand the comment, are you saying you can't correlate the headers that are incoming with the RPC call that generated them?
There was a problem hiding this comment.
Yes - within the body of an RPC handler, how do I access the headers that the client sent for that call?
|
|
||
| @Test | ||
| public void singleProperty() { | ||
| final MetadataAdapter headers = new MetadataAdapter(new Metadata()); |
There was a problem hiding this comment.
We probably need a CallHeaders implementation that doesn't come from the flight-grpc package, or there's no way to use HeaderCallOption.
| /** | ||
| * Interface for server side property handling. | ||
| */ | ||
| public interface ServerHeaderHandler extends Consumer<CallHeaders> { |
There was a problem hiding this comment.
I agree with @tifflhl's suggestion the name is too generic, would something like ServerPropertyHeaderHandler and ClientPropertyHeaderHandler be more appropriate similar to ClientBearerHeaderHandler.
| /** | ||
| * Set the header handler. | ||
| */ | ||
| public Builder headerHandler(ServerHeaderHandler headerHandler) { |
There was a problem hiding this comment.
Can we rename this to propertyHeaderHandler if we decide to rename ServerHeaderHandler
to ServerPropertyHeaderHandler?
There was a problem hiding this comment.
As mentioned in another comment, the intent is to handle all headers. You can interpret them as properties, but I think the name is reflective of intent.
|
Just a higher level comment - I see on ARROW-10428 cookie support is being worked on and ARROW-10427 is about session headers. Since cookies are a particular header and sessions are (usually) a particular cookie, is there any interest in making sure all these features work together and are built on top of each other? |
headers in FlightClient. Change how FlightServer accesses headers by requesting the ServerHeaderMiddleware via the CallContext in the RPC handlers.
|
Regarding the comment about sessions and cookies - yes, there is definite interest in making sure that the work there is building on top of, instead of parallel to, one another. |
|
@lidavidm any other comments on this? |
lidavidm
left a comment
There was a problem hiding this comment.
Overall looks good. Two minor comments.
java/flight/flight-core/src/main/java/org/apache/arrow/flight/FlightCallHeaders.java
Outdated
Show resolved
Hide resolved
java/flight/flight-core/src/main/java/org/apache/arrow/flight/HeaderCallOption.java
Outdated
Show resolved
Hide resolved
Fix bug trimming values from multi-valued headers when specifying as a HeaderCallOption.
|
Thanks @kylepbit! |
…nt headers. PR for https://issues.apache.org/jira/browse/ARROW-10467 Add a CallOption for specifying arbitrary properties as headers for RPC calls. Add a ServerMiddleware that will intercept and pass the properties to a handler when registered via the FlightServer builder. Closes apache#8572 from kylepbit/ARROW-10467 Authored-by: Kyle Porter <[email protected]> Signed-off-by: David Li <[email protected]>
PR for https://issues.apache.org/jira/browse/ARROW-10467
Add a CallOption for specifying arbitrary properties as headers for RPC calls.
Add a ServerMiddleware that will intercept and pass the properties to a handler
when registered via the FlightServer builder.