On 2/19/07, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
Try latest CVS version, it will work correctly now. Other solution to
remove charset parameters in the ns/paramaters section, this way no
encoding will be performed.
It works great, thanks!
Michael
Is there a way to disable using chunked encoding to reply to a
particular request?
AFAICT (with enabletclpages on), any *.tcl page under the documentroot will
have its content returned to the user with a Transfer-Encoding: chunked,
regardless of whether the request is HTTP/0.9, HTTP/1.0 or HTTP/1
On 2/10/07, Stephen Deasey <[EMAIL PROTECTED]> wrote:
You could try compiling the kernel with support for RTHREADS enabled.
Then compile the rthreads library in /usr/src/lib/librthread
Then link against it for 1-1 user-kernel threads.
Rather than recompiling OpenBSD I decided to start fresh a
On 2/10/07, Michael A. Cleverly <[EMAIL PROTECTED]> wrote:
My adventures (with CVS HEAD) on OpenBSD/sparc64 continue.
Unless I set:
ns_section "ns/server/${servername}/module/nssock"
ns_param acceptsize 1
in my conf file then incoming an HTTP r
My adventures (with CVS HEAD) on OpenBSD/sparc64 continue.
Unless I set:
ns_section "ns/server/${servername}/module/nssock"
ns_param acceptsize 1
in my conf file then incoming an HTTP request never get serviced
promptly; I can't connect to the nscp control port, and I
On 2/7/07, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
I updated configure.in in the CVS, can you run autogen.sh on CVS version
and see if it will detect it right.
it does:
checking for inet_ntop... yes
Thanks for all your help.
Michael
On 2/7/07, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
But when we check for inet_ntop there is no u_int8_t or other type
references, just inet_ntop(0, (char *)0, (char *)0, 0);
Can you check config.log for inet_ntop checking
It's needed by sys/socket.h which is included.
Here is that part of th
On 2/6/07, Stephen Deasey <[EMAIL PROTECTED]> wrote:
On 2/6/07, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
> On Linux HAVE_INET_NTOP is defined, i assume on OpenBSD not and
> the part with the union is not working
It should be defined, because it seems to have it:
http://www.openbsd.org/cgi-bi
On 2/6/07, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
Try this one:
#include
main()
{
unsigned char b[4];
struct in_addr addr;
addr.s_addr = inet_addr("127.0.0.1");
memcpy(b, &addr.s_addr, 4);
printf("%u.%u.%u.%u\n", b[0], b[1], b[2], b[3]);
}
That produces 127.0.0.1
On 2/6/07, Michael A. Cleverly <[EMAIL PROTECTED]> wrote:
On 2/6/07, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
> Try to compile this and see if you get 127.0.0.1 printed
>
> #include
>
> main()
> {
> struct in_addr addr;
> addr.s_addr = inet_a
On 2/6/07, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
Try to compile this and see if you get 127.0.0.1 printed
#include
main()
{
struct in_addr addr;
addr.s_addr = inet_addr("127.0.0.1");
printf("%s\n", ns_inet_ntoa(addr));
}
gcc -I /usr/local/ns/include -o a a.c /usr/local/ns/lib/l
I've compiled naviserver on OpenBSD 4.0/sparc64. What baffles me is
that [ns_conn peeraddr] always returns 0.0.0.0 for the client IP. The
access.log also shows 0.0.0.0 as the source IP address.
For example:
0.0.0.0 - - [05/Feb/2007:19:08:16 -0700] "GET / HTTP/1.1" 200 865 ""
"Mozilla/5.0 (Maci
On 9/18/06, Stephen Deasey <[EMAIL PROTECTED]> wrote:
I was wondering why registering a proxy handler is different than a
regular registered proc. Do they have to be different?
As I've been reading the NaviServer sources to acquaint myself I was
wondering the same thing.
The main difference
On 9/8/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
You are now added as developer.
Welcome on board.
Zoran
Thanks :-)
Michael
On 9/8/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
On 08.09.2006, at 22:12, Mike wrote:
> Zoran,
> We do not have a consistent, complete, documented, standalone,
> high-level database API. Sourceforge archives are crap, but you can
> see the relevant thread here:
> http://sourceforge.net
On 9/8/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
On 08.09.2006, at 21:52, Mike wrote:
> I think Michael failed to properly introduce himself. :) Michael
> is the author of nstcl: http://wiki.tcl.tk/3666 ... I can see no more
> perfect candidate for resolving the database interface is
I just discovered the existence of NaviServer last night (courtesy of
http://wiki.tcl.tk/2090). I don't know where I've been living for the
past year... but wow, I'm seriously impressed and extremely excited
about the existance of this project/fork!
When I get home tonight I plan on doing a cvs
17 matches
Mail list logo
