i have a suggestion to move NsTclRunAtClose(connPtr->itPtr); in connio.c
Ns_connClose before NsSockClose(connPtr->sockPtr, keep); to give atclose
handlers a chance to write something into still opened socket.
In most cases it will not be used and it will work as before because
atclose blocks and
On 07.11.2008, at 17:32, Vlad Seryakov wrote:
>
> Is everybody OK with this?
I can live with this.
Zoran
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applicat
On Fri, Nov 7, 2008 at 4:32 PM, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
> In most cases ... it will work as before because
> atclose blocks and socket is not yet returned to driver
driver.c:NsSockClose() does return the Sock to the driver thread, and
it does not block.
> ... if i need to use
On Fri, Nov 7, 2008 at 3:12 AM, Vlad Seryakov
<[EMAIL PROTECTED]> wrote:
> + # If address set to 0.0.0.0 in nssock to listen on
> + # all interfaces we may try to use Host: header to
> + # return proper urls
> + #
> +
> + if { $loc == "http://0.0.0.0"; } {
> + set host [n
Yes, bad change
Stephen Deasey wrote:
> On Fri, Nov 7, 2008 at 3:12 AM, Vlad Seryakov
> <[EMAIL PROTECTED]> wrote:
>
>> + # If address set to 0.0.0.0 in nssock to listen on
>> + # all interfaces we may try to use Host: header to
>> + # return proper urls
>> + #
>> +
>> + if {
Actually, i do not need it anymore
Stephen Deasey wrote:
> On Fri, Nov 7, 2008 at 4:32 PM, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
>
>> In most cases ... it will work as before because
>> atclose blocks and socket is not yet returned to driver
>
>
> driver.c:NsSockClose() does return the Sock
On Wed, Oct 22, 2008 at 8:58 PM, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
> Stephen Deasey wrote:
>> On Wed, Oct 22, 2008 at 9:03 PM, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
>>> I tried to use Ns_SockSendBufs() but it sends data directly to socket
>>> where i need to send via driver's send proc.
>
On Wed, Oct 22, 2008 at 10:35 PM, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
static ssize_t
Recv(Ns_Sock *sock, struct iovec *bufs, int nbufs, Ns_Time
*timeoutPtr, int flags)
{
static const char request[] = "GET /whateva HTTP/1.0\r\n\r\n";
size_t requestLen = siz
Great, thanks
>
>
> Fixed. For SSL (and for all drivers) just leave sendfFileProc as NULL
> and your sendProc will be called as needed to send file/buffer chunks.
>
> If you were writing something like an FTP server, then you would want
> to copy nssock and call Ns_SockSendFileBufs to optimise
>>> For example, In the snippet above, you can see the newly added
>>> Ns_ConnSockContent which returns a pointer to the read buffer (which
>>> is otherwise private). Ordinarily the buffer would contain the HTTP
>>> request line, any headers, then any body. You can get at the body with
>>> the exis
This is the simple PHP page that triggers hanging, when attached to the
nsd, backtrace on all thread show they all are in the condwait or poll
wait, seems like sent/expected bytes miscalculation.
test page
-
This SF.Net
On Fri, Nov 7, 2008 at 9:23 PM, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
>
> This is the simple PHP page that triggers hanging, when attached to the
> nsd, backtrace on all thread show they all are in the condwait or poll
> wait, seems like sent/expected bytes miscalculation.
>
>
> $test = @$_COOK
It is funny, using telnet and submitting same headers never triggers
this, but when using firefox, after sevrral requests it hangs, and after
timeout outputs:
0
c
test page
0
as it lost sequence and puts the whole buffer with trailer as the first
one. I want to find the problem and then wil
On Fri, Nov 7, 2008 at 10:24 PM, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
> I want to find the problem and then will put test for future checks
No, you write the test to help find the bug.
> It is funny, using telnet and submitting same headers never triggers
> this, but when using firefox, af
Added, runs fine but that the thing, it hangs in firefox, not in the test
Stephen Deasey wrote:
> On Fri, Nov 7, 2008 at 10:24 PM, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
>
>> I want to find the problem and then will put test for future checks
>
>
> No, you write the test to help find the bug.
On Sat, Nov 8, 2008 at 3:38 AM, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
>
> Added, runs fine but that the thing, it hangs in firefox, not in the test
>
OK, so there's a difference.
Maybe keepalive -- you mentioned what looked like responses garbled
together? An HTTP 1.1 request will force keepa
Yes, keep-alive is the key, nshttp_test closes connection so it cannot
test this
I tried that but could not get it to work, it generates configure but
when i run it i never could make it finish, there are always some errors.
Stephen Deasey wrote:
> On Sat, Nov 8, 2008 at 3:38 AM, Vlad Seryakov
In telnet session, i do it endlessly, no hangs, mistery
GET /test.php HTTP/1.1
Host: vlad.mpower.net
Cookie: test=1
HTTP/1.1 304 Not Modified
MIME-Version: 1.0
Server: NaviServer/4.99.3
Date: Sat, 08 Nov 2008 05:06:44 GMT
X-Powered-By: PHP/5.2.6
Set-Cookie: test=1; expires=Sat, 08-Nov-2008 05:07:
18 matches
Mail list logo
