Re: [naviserver-devel] NaviServer IOBUFSZ

[Stephen D. <sd...@gm...>]

On 5/23/07, Neophytos Demetriou <k2...@ph...> 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.