[ 
https://issues.apache.org/jira/browse/XERCESC-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607094#action_12607094
 ] 

Boris Kolpackov commented on XERCESC-1805:
------------------------------------------

Hi John,

Ok, I've commited a slightly-modified version of your changes (made 
getContentType pure virtual, moved the common implementation to NetAccessors/).

If you can provide a patch that fixes the following then I will be happy to 
review & commit it:

1. Don't use XMLString::transcode on the value of Content-Type
2. Make sure getContentType can be called after construction in Curl

While at it, perahps you could also fix up Curl implementation not to use local 
code page like you did for Sockect and Winsock. Curl is a default net accessors 
(if libcurl is available) on all UNIX/Linux platforms so it would be good to 
fix this.

Thanks,
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]

Reply via email to