Hi,
here are some thoughts about the capability negotiations.
Current status:
HTTP/OCP uses NO and NR messages to negotiate one of the two defined
application profiles (request or response) plus optional message parts.
Futher information exchange about capabilities for transfer- and
content-encodings needs to be defined and done.
Question:
Can we simplify the application profiles negotiation and how to implement the
encodings stuff?
Compare with ICAP/1.0:
ICAP defines the OPTIONS method; in a response to an OPTIONS request, the ICAP
server returns various information, including support for the main methods
(REQMOD/RESPMOD). But which method to use is not negotiated and ICAP does not
know something about optional message parts, skipped parts or information about
supported encodings.
If to be implemented it would probably be done in the OPTIONS request.
Do we really need to negotiate the HTTP profile?
Depending on the vectoring point, an OPES processor will either send a HTTP
request or an HTTP response via OCP to the callout server. It makes not much
sense to offer both profiles and let the callout server select.
All ICAP implementations I know and the rules language show: The decision which
profile to use is being done in the OPES processor.
Still the information whether a callout server at all supports this profile is
important; but it could be done in a "has feature" message, rather than in the
negotiation offer.
So, I vote for restricting the NO message to send a single application profile,
not a list of profiles.
The callout server can then either accept or decline.
Having a list of profiles can make the negotiation offer very long if
additional parameters are offered as an option. In the current draft we offer
additional message parts as options and adding more paramters would make this
much too long.
Other parameters
Client and server need to exchange information about (or negotiate on):
1. wanted additional optional message parts
server asks client
e.g. please add original HTTP request headers to HTTP response)
2. standard message parts not needed
server tells client
e.g. do not need long HTTP request body, only interested in headers
3. supported transfer encodings (or HTTP version)
client and server need to tell each other
e.g. is it ok for the server to add chunked transfer encoding?
4. supported content encodings
client and server need to tell each other
e.g. does the client need to decode gzip encoding before sending message
to server?
5. maybe additional parameters, specific for the callout server
e.g. number of parallel connections supported
6. maybe additional parameters, specific to the service to use
e.g. please add more meta information such as user info
I think it is not a good idea to create separate messages (negotiation offer or
has-feature) for each parameter although several messages could be sent in a
single TCP frame.
So, what about adding these paramters as named parameters to the NO and NR
messages. If the NO message has only a single application profile it works that
way.
Example:
NO "38:http://iana.org/opes/ocp/HTTP/response";
SG: 10
Optional-Parts: request-header, request-body
Transfer-Encodings: chunked
Content-Encodings: gzip, compress
NR "38:http://iana.org/opes/ocp/HTTP/response";
SG: 10
Optional-Parts: request-header
Skip-Parts: response-body
Transfer-Encodings: chunked
It means:
Client wants to do response modification with services in group ten.
It offers two additional optional message parts.
Client supported chunked transfer encoding and gzip and compress content
encoding
Server confirms that it can do response modification and asks for the
request-header as an optional message part.
If the client is able skip the response body part, it may do so.
Chunked transfer encoding is also supported by the server but if the message
has a content encoding, the client has either to decode it or the server won't
understand it (not a problem in this example because Skip-Parts header
indicates that it does not need the body at all.
What do you think about this? Can we do it that way?
Regards
Martin