> On Sep 14, 2018, at 8:57 AM, Andy Seaborne <[email protected]> wrote: > On 10/09/18 16:08, Niraj Patel wrote: >> Thank you both for replying! >>> Can you tell us more about your use case? Are the custom headers for some >>> one particular purpose? >> Sure! So our database, Allegrograph, allows us to pass down custom headers >> while querying or updating in order to store that information in access >> logs. For each SPARQL request we want to send down unique request markers >> and usernames in order to be able to trace from a UI click to backend calls >> to queries that were performed in the graph. Does that make sense? Do y’all >> have any ideas now that y’all know the use case? > > Makes sense. > > Adding HTTP header inform to track an operation end-to-end. > > What might work is to have a point in the HttpOp execution flow that sees the > HttpGet/HttpPost/... request just before it is acted upon.
Yes, this use case is quite reasonable. A couple of immediate options: 1. You can repeatedly swap out the client while changing default headers, as Andy describes, and that may work fine, especially if you keep a pool of clients and don't keep building completely fresh ones. 2. You can put some sort of proxy in place between your Jena client and Allegrograph, which adds the appropriate headers. That might or might not be workable depending on how you're sourcing the info to build the headers. 3. You can use low-level methods like building your own HTTP client, and Query::serialize to fill requests with your SPARQL. (There might be something better to use than Query::serialize for that.) For the future, Andy's suggestion of a "hook" in HTTP execution for manipulating requests sounds like a good one. Would that meet your needs, and if so, will you please file a ticket for it? ajs6f
