[
https://issues.apache.org/jira/browse/XERCESC-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606726#action_12606726
]
Boris Kolpackov commented on XERCESC-1805:
------------------------------------------
Hi Jonh,
I don't know, it all feels wrong. Let's assume we specify that getContentType()
returns "media-type" as defined in the HTTP 1.1 spec. The next issue is when
can getContentType() be called? I would assume most users would want to know
the content type before actually reading any data. But this does not seem to be
valid for HTTP: getContentType can only be called after readBytes (before that
the request hasn't been made so the content type is not known; I wonder how do
you even use something like this in XQilla...). So I feel uncomfotable putting
getContentType which appears to be very closely tied to the HTTP stream into
the base interface. Any thoughts on this?
Another issue that I noticed is that you use XMLString::transcode on the value
of Content-Type which assumes that it is in local code page. But this is minor
so perhaps you can submit a small patch later once I commit the major changes.
Boris
> 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]
