Opened 16 years ago
Closed 14 years ago
#2583 closed defect (fixed)
add charset in content-type http header
Reported by: | bartvde | Owned by: | dmorissette |
---|---|---|---|
Priority: | normal | Milestone: | 5.6 release |
Component: | WFS Server | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: | aboudreault, assefa, tomkralidis |
Description
Hi list,
currently Mapserver (WFS e.g.) only uses the encoding METADATA in the XML header of the XML document.
For AJAX applications in Internet Explorer, this is often not enough to get the XML to be parsed, if it contains specials characters.
Instead, it should also be added to the Content-Type http header charset, e.g.:
Content-Type: text/xml;charset=ISO-8859-1
Should I open up a bug for this enhancement?
Best regards, Bart
Attachments (1)
Change History (20)
comment:1 by , 16 years ago
Component: | MapServer CGI → WFS Server |
---|---|
Owner: | changed from | to
comment:2 by , 16 years ago
Milestone: | → 5.2 release |
---|
comment:3 by , 16 years ago
Milestone: | 5.2 release → 5.4 release |
---|---|
Owner: | changed from | to
comment:4 by , 15 years ago
Cc: | added |
---|---|
Milestone: | 5.4 release → 6.0 release |
comment:5 by , 14 years ago
Milestone: | 6.0 release → 5.6 release |
---|
comment:6 by , 14 years ago
Cc: | added |
---|
I suppose that all those methods should use the "*_encoding" metadata, as they do for the xml tag encoding attribute. Assefa, do you have any hint on that ? Do you think that replacing all the msIO_printf("Content-type: text/xml%c%c",10,10); lines by the following code would be the proper solution?
msOWSPrintEncodeMetadata(stdout, &(map->web.metadata), "FO", "encoding", OWS_NOERR, "Content-type: text/xml; charset=%s\n\n", "ISO-8859-1");
comment:7 by , 14 years ago
Hmmm. I see that this function also use the msEncodeHTMLEntities function, don't know if that can break something when printing the header.
comment:8 by , 14 years ago
I'll do it safely and put the patch here. Perhaps Assefa will have the time to review it or someone else.
comment:9 by , 14 years ago
Would we need to update code that uses libxml2 to output the XML as well?
follow-up: 11 comment:10 by , 14 years ago
Here's a patch that include the charset (*_encoding) in the header.
comment:11 by , 14 years ago
Replying to aboudreault:
Here's a patch that include the charset (*_encoding) in the header.
I just realized that libxml2 is not involved in the Content-type output (rather msIO_printf).
Small comment on the msOWSLookupMetadata to look up encoding. Should the namespace be a global "O", instead of "MO", "FO", etc.? I think this value is generic enough, unless there are specific use cases which indicate otherwise.
follow-up: 14 comment:12 by , 14 years ago
Since the encoding attribute of the xml tag uses the namespace "FO" etc.., I thought it would make sense to do the same thing for the Content-Type. Otherwise, we could get a Content-Type charset different than the xml encoding itself. what do you think?
follow-up: 15 comment:13 by , 14 years ago
Cc: | added |
---|
From what I can see, the patch seems ok (famous last words :) I just checked the msautotest and I believe It will break all the WxS tests that do output xml. Maybe we should just output the encoding for the content type only if it is defined; else leave it as it is now. comments?
comment:14 by , 14 years ago
Replying to aboudreault:
Since the encoding attribute of the xml tag uses the namespace "FO" etc.., I thought it would make sense to do the same thing for the Content-Type. Otherwise, we could get a Content-Type charset different than the xml encoding itself. what do you think?
Thanks for clarifying. OK.
comment:15 by , 14 years ago
Replying to assefa:
From what I can see, the patch seems ok (famous last words :) I just checked the msautotest and I believe It will break all the WxS tests that do output xml. Maybe we should just output the encoding for the content type only if it is defined; else leave it as it is now. comments?
+1.
comment:16 by , 14 years ago
What should be the real proper behavior? Couldn't we modify WxS tests ? (if the proper behavior is what the current patch does)
comment:17 by , 14 years ago
I think the "correct" way might be to always send the encoding (although I did not find the specs that would say). But I think that in our case, keeping the current behavior if encoding is not defined in the map is the safest way to go.
comment:18 by , 14 years ago
I agree with passing encoding in the header only if the metadata is explicitly set, to reduce the chances of breaking something.
comment:19 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
When the metada is explicitly set, the charset encoding will be added in the header.
Fixed and committed in r9492.
Hmmm... I wonder who this should go to? The CGI allows you to define your own document type via QUERYFORMAT or BROWSEFORMAT so you can add the extra information there. You can control that in OUTPUTFORMATs too. The OGC interfaces don't use those methods though. I think I'll assign to WFS server though since that looks to be where it would be used often.
Steve