Returning status to host application after calling useAdapted

Asked by John Jacob on 2014-08-18

Hello,

We have a response adapter where we always call 'useAdapted', but after we have then begun returning the adapted body to the client we may want to log a status to the host (Squid) log files for the request, if we encounter a specific condition whilst adapting the body.

We were previously using meta information/headers to achieve this, by setting an entry in visitEachOption(). However, we find that (for Squid at least) any options are only added to the shared metadata (and available for logging) at the point of the call to 'useAdapted', so this only works if we hold back content in a buffer before calling useAdapted() or useVirgin(). If we set an option for visitEachOption() after the call to useAdapted() (once we are already sending content) then this option does not seem to be made available to the host for logging.

Is this expected, and are there any workarounds for returning status to the host (for logging) after we have begun adapting the body?

Thanks in advance,
John

Question information

Language:
English Edit question
Status:
Answered
For:
eCAP Edit question
Assignee:
No assignee Edit question
Last query:
2014-08-18
Last reply:
2014-08-18
Alex Rousskov (rousskov) said : #1

You have a general and reasonable need, but there is currently no eCAP API to support it directly. I can recommend the following:

Short term: Teach your host application to re-request transaction metadata at the end of a transaction. You can contact Squid developers about that. If you can provide the Squid Project with a patch, they may be able to accommodate you sooner, but a patchless "new feature request" filed with Squid bugzilla might be sufficient.

Long term: We should add libecap::host::Xaction::noteNewOptions(void) or a similar API for the adapter to signal metadata updates to the host application. This API change can be done in the next eCAP library release. The host application receiving the notification would then re-query the adapter for new options. This solution allows the adapter to control the timing and frequency of those [potentially performance-expensive] metadata updates. I suggest opening an eCAP bug report here on Launchpad to suggest that API addition.

John Jacob (jkillimangalam) said : #2

Thanks Alex. We will explore the options mentioned by you.

Alex Rousskov (rousskov) said : #3

For the record, there is another question about trailers-like API changes: https://answers.launchpad.net/ecap/+question/537116

Can you help with this problem?

Provide an answer of your own, or ask John Jacob for more information if necessary.

To post a message you must log in.