NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Paolo,Many thanks for your considered reply. I was away last week hence the delay replying.
Some comments on your points:1) the OWSLib client doesn't expect a MIME-Version header field in each body part - I think this is just an idiosyncrasy of the library the server used on the server to write the multipart MIMEs. So I don't think this will be the cause of any problems.
2) Ok yes possibly. Is this fixed already on your server? If so I will try it out again.
3) Thanks, I missed that - I'll change it. Regards, Dominic On Friday 01 August 2008 18:13:24 Paolo Mazzetti wrote:
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 MIME-conformant." 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. http://ndgbeta.badc.rl.ac.uk/wcs/badc.nerc.ac.uk__NDG-A0__AWQX8gTc?Service= WCS&request=GetCoverage&version=1.1.0&TimeSequence=2024-01-15T00:00:00.0&For mat=cf-netcdf&store=false&BoundingBox=-80,10,80,100&Identifier=EhWv0qW5). 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. Best regards, Paolo
galeon archives: