NOTE: The galeon
mailing list is no longer active. The list archives are made available for historical reasons.
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&Format=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: