On 5/23/07, Neophytos Demetriou <[EMAIL PROTECTED]> wrote:
> Try:
>
> ns_return 200 text/html [encoding system]-[string repeat X 10000]
>
> With:
>
> ns_param hackcontenttype true
> ns_param outputcharset utf-8
> ns_param urlcharset utf-8
> ns_param preferredcharsets { utf-8 iso8859-1 }
>
> and then try the same thing by commenting out the outputcharset line.
> Without outputcharset, it works. With outputcharset, it doesn't (data >
> 8192).
>
> I've placed a logging statement just before Ns_ConnSetRequiredHeaders in
> ReturnCharData (return.c):
>
> * Without outputcharset - ReturnCharData: len=10007 sendRaw=1 hlen=10007
>
> * With outputcharset - ReturnCharData: len=10007 sendRaw=0 hlen=10007
>
> > e.g., for a current project, we use the server the way Zoran said once
> > on the list: use it out of the box and rely on the Unicode encoding.
> > The strange thing is, that, when on the other hand explicitely
> > verbosely setting the outputcharset (et.al) parameter to utf-8, it
> > breaks.
>
> True. The only reason I mention this here is because it works for
> aolserver. I suppose there is a good reason that things are done
> differently.
Actually no, this is probably broken...
Just to be clear though for this particular case: when outputcharset
is not set in the config file it works, and when it is it doesn't --
do you mean just that your browser shows a blank page or have you
observed something more specific, like an incorrect Content-Length
header, etc.?
I'm taking a look at this. Thanks for reporting.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
