From: Alex M. <ami...@je...> - 2005-12-29 00:08:23
|
I submitted a bug awhile back with a patch: http://sourceforge.net/tracker/index.php?func=detail&aid=1338988&group_id=17691&atid=117691 The patch is out of date now but the insertion line now has moved to line 1033 What is the procedure for getting this integrated into the codebase? I just submitted another bug with a patch that fixes it for HTTP basic auth. Before the patch gets cold... :) --Alex Milowski |
From: Dannes W. <di...@gm...> - 2005-12-29 15:29:11
|
Hi Alex On 12/29/05, Alex Milowski <ami...@je...> wrote: > > I submitted a bug awhile back with a patch: > > > http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1338988&grou= p_id=3D17691&atid=3D117691 > > The patch is out of date now but the insertion line now has moved to > line 1033 thnx for you patch ; sorry the patch slipped our minds, I'll review the proposed changes and update the code. Are you sure about line 1033? What is the procedure for getting this integrated into the codebase? Ask one of the developers to apply. If we get a .patch file, the code is normally inserted quickly.... I just submitted another bug with a patch that fixes it for HTTP basic > auth. Before the patch gets cold... :) Giulio applied this patch, thnx again! regards Dannes -- # Dannes Wessels # The Netherlands # # Jabber / ICQ / MSN / AIM / Yahoo / google.com/talk # |
From: Alex M. <ami...@je...> - 2005-12-29 17:27:28
|
Dannes Wessels wrote: > Hi Alex > > On 12/29/05, *Alex Milowski* <ami...@je... > <mailto:ami...@je...>> wrote: > > I submitted a bug awhile back with a patch: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1338988&group_id=17691&atid=117691 > <http://sourceforge.net/tracker/index.php?func=detail&aid=1338988&group_id=17691&atid=117691> > > The patch is out of date now but the insertion line now has moved to > line 1033 > > > thnx for you patch ; sorry the patch slipped our minds, I'll review the > proposed changes and update the code. Are you sure about line 1033? > Ah, my bad. Looked at the wrong bit in vi! :) I've updated the patch in the bug repository with the following changes: * extracted the charset from after the semicolon * if the charset is specified, the source is opened using the charset parameter for the encoding rather than using auto-detection. Now, is there some set of unit tests I can run this through to see if everything is OK? It should operation exactly the same as before if you don't specitify the charset parameter on the content type. If you now specify a content type like: Content-Type: text/xml; charset=UTF-16 it will not only properly recongize the mime type but also use the charset when decoding the bytes sent. That is something that my previous patch did not do. The remaining issue here is that if I post non-XML data that should be served up with a particular encoding (e.g. text/plain; charset=UTF-16), the data will be stored verbatim and the retrieval won't use the request's charset. Overall, it might be nice to have a per-resource facet that has the preferred character encoding. That could be set to whatever was used in the PUT request. --Alex Milowski |