I already had -DNO_THREADS set. I forgot to mention that before I did that,
the behavior was a bit more unpredictable. When I had it configured that
way, I would still get frozen connections with IE, but sometimes a second
browser (such as firefox) would still work.

Implementing your second suggestion appears to cause the problem to go away.
Is this something I can leave like this without fear of further problems, or
was it only meant as a diagnostic aid?

Also, while trying to figure this out, I noticed a discrepancy with the way
shttpd handles Etag headers, I noticed the following:
Client sends:
GET /images/alarm.GIF HTTP/1.1
Accept: */*
Referer: http://localhost:81/home.html
Accept-Language: en-us
Accept-Encoding: gzip, deflate
If-Modified-Since: Mon, 01 Jan 2007 00:00:00 GMT
If-None-Match: "4598a360.9fe"
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR
1.1.4322; .NET CLR 2.0.50727)
Host: localhost:81
Connection: Keep-Alive

The server then sends back:
HTTP/1.1 200 OK
Date: Wed, 27 Aug 2008 08:43:05 GMT
Last-Modified: Mon, 01 Jan 2007 00:00:00 GMT
Etag: "4598a360.9fe"
Content-Type: image/gif
Content-Length: 2558
Accept-Ranges: bytes

<<The requested file, trimmed for brevity.>>

If I understand the If-None-Match: header correctly, the response should
have been a 304 (Not Modified) plus some cache related headers. It's quite
possible that I'm wrong about this, and it doesn't appear to cause any
functional problem, but it probably means that the server is defeating some
bandwidth conservation measures that the client may implement.



On Wed, Aug 27, 2008 at 1:36 AM, Sergey Lyubka <[EMAIL PROTECTED]> wrote:

> Please do two things:
>   1. switch on -DNO_THREADS compilation flag
>   2. switch off keep-alive. in shttpd.c : connection_destructor() function,
> before the line "if (!do_close ..)", insert line "do_close = 1".
>
> On Tue, Aug 26, 2008 at 10:28 PM, Joshua Van Tol <[EMAIL PROTECTED]>wrote:
>
>> I'm quite a newbie at http/webservers, so hopefully I can make my question
>> clear.
>>
>> I'm developing an embedded app using shttpd-1.42, and I'm noticing that
>> shttpd will sometimes freeze up when the client is ie 6.0. IE 7, and firefox
>> don't seem to cause this problem.
>>
>> The observable symptom (as seen with tcpTrace) is that a request for
>> static content (or sometimes dynamic content) is sent, and no response ever
>> comes back. From this point onwards, the server is unresponsive to http
>> requests.
>>
>> Digging a bit, I turned on -D_DEBUG and found that the call to select in
>> do_select (shttpd.c) is returning -1, and an errno of 10038, which after
>> taking into account the windows convention of adding 10,000 to error
>> numbers, translates into "*WSAENOTSOCK (10038)* *Socket operation on
>> non-socket*." This problem only surfaces once the symptom above has
>> occurred.
>>
>> So, any pointers on how I might debug this problem further?
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> shttpd-general mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/shttpd-general
>>
>>
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
shttpd-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shttpd-general

Reply via email to