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)

2583.patch (25.2 KB ) - added by aboudreault 14 years ago.
Patch to include encoding charset in the header

Download all attachments as: .zip

Change History (20)

comment:1 by sdlime, 16 years ago

Component: MapServer CGIWFS Server
Owner: changed from sdlime to mapserverbugs

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

comment:2 by dmorissette, 16 years ago

Milestone: 5.2 release

comment:3 by dmorissette, 16 years ago

Milestone: 5.2 release5.4 release
Owner: changed from mapserverbugs to dmorissette

comment:4 by dmorissette, 15 years ago

Cc: aboudreault added
Milestone: 5.4 release6.0 release

comment:5 by dmorissette, 14 years ago

Milestone: 6.0 release5.6 release

comment:6 by aboudreault, 14 years ago

Cc: assefa 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 aboudreault, 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 aboudreault, 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 tomkralidis, 14 years ago

Would we need to update code that uses libxml2 to output the XML as well?

by aboudreault, 14 years ago

Attachment: 2583.patch added

Patch to include encoding charset in the header

comment:10 by aboudreault, 14 years ago

Here's a patch that include the charset (*_encoding) in the header.

in reply to:  10 comment:11 by tomkralidis, 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.

comment:12 by aboudreault, 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?

comment:13 by assefa, 14 years ago

Cc: tomkralidis 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?

in reply to:  12 comment:14 by tomkralidis, 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.

in reply to:  13 comment:15 by tomkralidis, 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 aboudreault, 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 assefa, 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 dmorissette, 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 aboudreault, 14 years ago

Resolution: fixed
Status: newclosed

When the metada is explicitly set, the charset encoding will be added in the header.

Fixed and committed in r9492.

Note: See TracTickets for help on using tickets.