[
https://issues.apache.org/jira/browse/XERCESC-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606799#action_12606799
]
John Snelson commented on XERCESC-1805:
---------------------------------------
Hi Boris,
The getContentType() method can be called after construction of the relevant
BinInputStream implementations, since the HTTP headers are read during
construction.
I fixed a number of transcoding bugs in the original HTTP BinInputStream
implementations, so I must have missed the one you're talking about. Another
patch to fix that issue should be simple to add.
John
> Accessing the HTTP Content-Type
> -------------------------------
>
> Key: XERCESC-1805
> URL: https://issues.apache.org/jira/browse/XERCESC-1805
> Project: Xerces-C++
> Issue Type: Improvement
> Components: Miscellaneous
> Affects Versions: 3.0.0
> Reporter: John Snelson
> Fix For: 3.0.0
>
> Attachments: xercesc_3_0_content_type_patch
>
>
> A lot of algorithms need access to the HTTP "Content-Type" header, to decide
> how to parse a file, or what encoding it is in - for instance see XSLT 2.0's
> unparsed-text() function:
> http://www.w3.org/TR/xslt20/#unparsed-text
> We should add a method, BinInputStream::getContentType(), and implement it in
> the HTTP input stream implementations. The method should return 0 when the
> content type is not available, like for file input streams.
> In addition, the socket and WinSock HTTP InputStream implementations have a
> number of problems:
> 1) They used fixed buffers which can result in buffer overflow.
> 2) They needlessly duplicate a whole load of code that could be shared.
> 3) They transcode to the local code page rather than "ISO8859-1".
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
