I have tried to look through all the ICAP mail to see if these inconstinencies
were reported
or not - I didn't see them. The second problem is the same as the problem
discussed in this thread, but just one more data point.
1. Examples show commas separating encapsulated sections, as in
encapsulated: req-hdr=0, reqbody=200
but syntax in 5.4 does not have the separating comma.
2. Syntax in 5.4 does not allow the req-body for response mod as in 5.4.1.
Craig
Jeremy Elson <jelson(_at_)ISI(_dot_)EDU> 12/11/00 11:48PM >>>
OK, there was a disconnect somewhere. The spec says different things
in different places. Your Encapsulation section shows that request
bodies are not allowed but elsewhere we have (emphasis mine)
5.8 Response Modification Mode
In this method, described in Section 4.3, an ICAP client sends an
origin server's HTTP response to an ICAP server, AND (IF AVAILABLE)
THE ORIGINAL CLIENT REQUEST THAT CAUSED THAT RESPONSE. Similar to
Request Modification method, the response from the ICAP server can be
an adapted HTTP response, an error, or a 204 response code indicating
that no adaptation is required.
Also in Section 5.4.1 we have
Response Modification
request: req-hdr=n res-hdr=n req-body=n res-body=n
response: res-hdr=n res-body=n
I couldn't find anything in the previous meeting notes about getting
rid of the 2nd post body. It must have slipped past me in the flurry
of things we agreed on at the last minute. We can fix this in an -01
version of the spec.
Donald Gillies writes:
No, we removed that from the spec about 4 weeks ago, when we decided
that it was too late to do anything about the POST body by the time
you get to response modification, and we could find no application
that actually needed the POST body, and we found that the ICAP
service could get the POST body from a REQMOD (and they'd have the
option to change it with a REQMOD).
Check the syntax. It shouldn't be there now. We made this decision
4 weeks ago.
- DOn