Dear Dominic and all,
concerning your test with our WCS 1.1.0 server we (Mattia Santoro and I) analyzed our server responses. Actually they look correct, but the response "content not allowed in prolog" during XML parsing usually comes from some encoding problem. Thus we are examining our code to verify if an encoding mismatch occurs somewhere between xml prolog, http header declaration and actual data encoding.
By the way comparing our and your servers responses we found the following
differences and problems:
1) Your response includes the "MIME-Version" header field in each body part while ours does not. We do not
think that this should be a problem, but if your client expects it an error could be raised. Please note that the
specifications (RFC 2045) state that "the MIME-Version header field is required at the top level of a message.
It is not required for each body part of a multipart entity. It is required for the embedded headers of a body of type
"message/rfc822" or "message/partial" if and only if the embeddedmessage is itself claimed to be
2) We found a small error in our response: a double ";" before the "charset" attribute in the HTTP header. This is sintactically correct but depending on the http client library behaviour, it could be one of the reasons for the possible character encoding error previously described.
3) We also found a problem in your server responses (e.g.
It does not include the XML prologue and the first tag (<coverages>).
Generally speaking we are currently revising the multipart response. In
particular we are considering the following modifications:
a) The message should be multipart/related instead of multipart/mixed
since the semantics of multipart/related better fits our case.
b) The Content-ID should be world-unique.
We still have not implemented this modifications in our server, but I am going to better
detail them in a paragraph of the document "WCS extensions for CF-NetCDF 3"
that Stefano is preparing.