Re: section 2.6 HTTP Header Correctness of HTTP adaptation draft
what if incoming HTTP message is already in violation of the
HTTP spec. Are we saying that OPES processor has to fix it? Should we
cover that case implicitly: "Assuming compliant input, ..."
No, we should not force the OPES processor to fix HTTP headers before
sending to the callout service. It makes no sense to put this extra
burdon on the processor, because we define later:
An OPES processor MAY forward the response of a callout service to
other callout services without verifying HTTP header correctness.
Consequently, a callout service cannot assume that the HTTP headers
it receives are correct or final from an HTTP point of view.
So, for a callout server it should not make a difference whether it
sees incorrect incoming headers or incorrect headers from a previous
callout service.
What do you think about changing the beginning of section 2.6 from
current "HTTP OPES processors MUST ensure..." to "When communicating
with other HTTP applications, OPES processors MUST ensure..."
On the other hand the OPES processor has a problem if it trusts an
incorrect incoming Content-Length header and therefore sends an
incorrect AM-EL size. Is there anything we could do against this?
Should we document this in any way?
Regards
Martin