shttpd-general — All sort of questions regarding SHTTPD

Re: [shttpd-general] Memory leak

[Sergey L. <va...@gm...>]

Right, I found what was that leak you've found.
It is not-freed context, which did not have time to dealloc after getting
the stop signal.
if you put sleep(1) in main.c, just before returning from main(), it'll fix
this leak.

The proper fix will be when all mg_* functions will the mutex-guarded, to
mg_stop would not return until the serving thread has exited.

On Tue, Dec 2, 2008 at 3:24 PM, Sergey Lyubka <va...@gm...> wrote:

> Valgrind tests revealed the fact that I was using joinable threads. Changed
> to detached, fix submitted.
> It looks like there is no leaks in the current code.
>
>
> On Tue, Dec 2, 2008 at 2:50 PM, Sergey Lyubka <va...@gm...> wrote:
>
>> Thanks Antonio!
>> You'd better use new mailing list,
>> http://groups.google.com/group/mongoose-users
>> Also, it is enough to say file version numbers, instead of including them
>> ($Id$ is properly substituted now).
>>
>> I am looking at the problem, running valgrind myself. From your output,
>> I'd say there is no leak there, but let me double check.
>> Note that I checked in couple of fixes in the code already.
>>
>> Thanks again for the early tests, I appreciate it!
>>
>>
>

Re: [shttpd-general] Memory leak

[Sergey L. <va...@gm...>]

Valgrind tests revealed the fact that I was using joinable threads. Changed
to detached, fix submitted.
It looks like there is no leaks in the current code.

On Tue, Dec 2, 2008 at 2:50 PM, Sergey Lyubka <va...@gm...> wrote:

> Thanks Antonio!
> You'd better use new mailing list,
> http://groups.google.com/group/mongoose-users
> Also, it is enough to say file version numbers, instead of including them
> ($Id$ is properly substituted now).
>
> I am looking at the problem, running valgrind myself. From your output, I'd
> say there is no leak there, but let me double check.
> Note that I checked in couple of fixes in the code already.
>
> Thanks again for the early tests, I appreciate it!
>
>

Re: [shttpd-general] Memory leak

[Sergey L. <va...@gm...>]

Thanks Antonio!
You'd better use new mailing list,
http://groups.google.com/group/mongoose-users
Also, it is enough to say file version numbers, instead of including them
($Id$ is properly substituted now).

I am looking at the problem, running valgrind myself. From your output, I'd
say there is no leak there, but let me double check.
Note that I checked in couple of fixes in the code already.

Thanks again for the early tests, I appreciate it!

[shttpd-general] Memory leak

[Aguilar, A. <ant...@de...>]

Hi Sergey,

While running valgrind and siege tests I have found a memory leak in mongoose (linux version).

I run valgrind as follows:

$ valgrind --tool=memcheck --leak-check=full ./main -ports 8080 -root ./website/

==16711== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 1)
==16711== malloc/free: in use at exit: 49,619 bytes in 369 blocks.
==16711== malloc/free: 2,935 allocs, 2,566 frees, 576,641 bytes allocated.
==16711== For counts of detected errors, rerun with: -v
==16711== searching for pointers to 369 not-freed blocks.
==16711== checked 3,007,951,384 bytes.
==16711== 
==16711== 49,096 bytes in 361 blocks are possibly lost in loss record 4 of 4
==16711==    at 0x4023DE2: calloc (vg_replace_malloc.c:397)
==16711==    by 0x4010A1B: _dl_allocate_tls (in /lib/ld-2.8.90.so)
==16711==    by 0x4045672: pthread_create@@GLIBC_2.1 (in /lib/tls/i686/cmov/libpthread-2.8.90.so)
==16711==    by 0x804BF6A: mg_start (mongoose.c:647)
==16711==    by 0x8049FF7: main (main.c:249)
==16711== 
==16711== LEAK SUMMARY:
==16711==    definitely lost: 0 bytes in 0 blocks.
==16711==      possibly lost: 49,096 bytes in 361 blocks.
==16711==    still reachable: 523 bytes in 8 blocks.
==16711==         suppressed: 0 bytes in 0 blocks.
==16711== Reachable blocks (those to which a pointer was found) are not shown.
==16711== To see them, rerun with: --leak-check=full --show-reachable=yes

from valgrind output, there are missing 'frees' 

==16711== malloc/free: 2,935 allocs, 2,566 frees, 576,641 bytes allocated.

to trigger the memory leak, I use siege as follows:

$ siege -c 10 -r 10 http://localhost:8080/index.html

this creates 10 concurrent connections (with 10 repetitions each) which get the index.html file. I run this command 3 times, then I get the following messages:

start_thread: Invalid argument
start_thread: Invalid argument
start_thread: Invalid argument
start_thread: Invalid argument

and mongoose hangs.

Attached are the source versions of the files I'm using.

A.

Re: [shttpd-general] Moving to code.google.com

[Sergey L. <va...@gm...>]

> http://msdn.microsoft.com/en-us/vs2008/products/cc268305.aspx
>

Cool, thanks! No doubt native 64 bit support is a way to go.

Re: [shttpd-general] Moving to code.google.com

[David L. <da...@sa...>]

BTW, you can get a free download of VS2008 that runs for 90 days at link below.

http://msdn.microsoft.com/en-us/vs2008/products/cc268305.aspx

 

It is worth the time because the VS2008 compiler does excellent job of pointing out portability issues, as well as just pointing out likely programmer errors if you compile with all warnings on. The windows debugger alone is worth the investment in time.

 

From: Sergey Lyubka [mailto:va...@gm...] 
Sent: Monday, December 01, 2008 2:54 PM
To: David Lethe
Cc: shttpd-general
Subject: Re: [shttpd-general] Moving to code.google.com

 

David,

I think this mailing list is exactly the right place for this sort of things. Thanks a lot for your effort!

I'll get back on that when I start to work on Win32 side,  which will happen very soon, not later than this weekend. After being quite busy at work recently, now I seem to get some free time, which I'd like to spend on finishing the move.

I will be using MSVC6, which is an old compiler, my ignorant guess is that 32-bit executable it generates can be run on Win64 without any trouble. 

Sergey

Re: [shttpd-general] Moving to code.google.com

[David L. <da...@sa...>]

From: Sergey Lyubka [mailto:va...@gm...] 
Sent: Monday, December 01, 2008 2:54 PM
To: David Lethe
Cc: shttpd-general
Subject: Re: [shttpd-general] Moving to code.google.com

 

David,

I think this mailing list is exactly the right place for this sort of things. Thanks a lot for your effort!

I'll get back on that when I start to work on Win32 side,  which will happen very soon, not later than this weekend. After being quite busy at work recently, now I seem to get some free time, which I'd like to spend on finishing the move.

I will be using MSVC6, which is an old compiler, my ignorant guess is that 32-bit executable it generates can be run on Win64 without any trouble. 

Sergey

On an x64 platform, it isn’t that big of a deal to just compile in 32-bit mode, but on an IA64 platform, you not only take a big CPU hit if not doing native, but have to install a full X86 emulation layer onto the O/S.    With VS2008, Vista, virtualization, and MSFT’s desire to move people to 64-bit native computing, it is best to just bite your lip and go with the flow and add the typecasting necessary  to run 64-bit apps in 64-bit mode.    32-bit apps that run on 64-bit MSFT operating systems have to deal with things like WOW; multiple sets of registries; 2 “Program Files” directories;  special handling for an installer; 

Yuk.   So much easier to make the app compile natively on both 32 & 64-bit.

Also since most of the UNIX variants use 64-bit variables and file systems such as ZFS can handle massively large files and structures,  then sooner or later an app such as this is going to need to be tweaked for full 64-bit support .. might as well do it now before you release this.  

Re: [shttpd-general] Moving to code.google.com

[Sergey L. <va...@gm...>]

David,

I think this mailing list is exactly the right place for this sort of
things. Thanks a lot for your effort!

I'll get back on that when I start to work on Win32 side,  which will happen
very soon, not later than this weekend. After being quite busy at work
recently, now I seem to get some free time, which I'd like to spend on
finishing the move.

I will be using MSVC6, which is an old compiler, my ignorant guess is that
32-bit executable it generates can be run on Win64 without any trouble.

Sergey

Re: [shttpd-general] Moving to code.google.com

[David L. <da...@sa...>]

I made a quick pass at trying to modify mongoose so it will compile and run under Windows with VS2008.  It is clear you haven't finished the Windows-specific code, but I did see some issues you might want to address before you go much further.

VS2008 uses 64-bit time as default.  This will break logic since you assume the time-related structures are all 32-bits.  The _USE_32BIT_TIME_T will force compiler & linker to use 32-bit time.   MSFT also gives you several flavors of stat function based on whether or not you want 32 or 64-bit structures.   VS2008 throws out warnings with the current code saying you are comparing 32-bit with 64-bit numbers.   Structures such as ones returned by stat function will definitely break with your current source code on WIN64 platforms.   Also look at the file-related functions like seek so you handle 64-bit file systems.

On Win64 platforms, datatypes SOCKET is UINT_PTR, a 64-bit value.   So when you test for (sock != -1) on such a platform then it won't necessarily work .... 

The MSDN way of testing for invalid sockets is below
#if defined (_WIN32) || defined (_UNIX)
  #define MY_SOCK_ERROR            INVALID_SOCKET /* Socket not valid/init'd*/
  typedef SOCKET                           MY_SOCKID; /* Socket Id */
#else
#define MY_SOCK_ERROR            -1 /* Socket not valid/init'd */
typedef int                                     MY_SOCKID; /* Socket Id */
#endif /* defined (_WIN32) */


if (sock == MY_SOCK_ERR)
  goto fail;

 
If you prefer this stuff stay off the list to keep traffic down, then let me know.
David

Re: [shttpd-general] Moving to code.google.com

[Sergey L. <va...@gm...>]

> Will you include the 100-continue fix from Christian?
>

Yes, I plan to put in all pending patches.

Re: [shttpd-general] Moving to code.google.com

[Leslie P. P. <sk...@vi...>]

> Next release will be on code.google.com. It will include threading model,
> and API simplification.

Thank you, Sergey.

Will you include the 100-continue fix from Christian?

  Leslie

-- 
LinkedIn Profile: http://www.linkedin.com/in/polzer
Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
Blog: http://blog.viridian-project.de/

Re: [shttpd-general] Moving to code.google.com

[Sergey L. <va...@gm...>]

+shttpd-general

On Sat, Nov 29, 2008 at 10:22 PM, Sergey Lyubka <va...@gm...> wrote:

>
>
>> Could a get a pre-release of the unix version? - I will be more than happy
>> to do some additional testing ;-)
>>
> Yes, it is in CVS, submitted.
>
> Also, I'm wondering how embeddable/portable the new version is? Because I'm
>> considering porting the code to a Symbian platform. I'm not sure if this is
>> within the scope of the new release but I will happy to help and give it a
>> try.
>>
>> A.
>>
>
> I do not plan to degrade the portability, although I do not have an access
> to some platforms. This may result in some portability issues, but this
> stands true for virtually every release.
>

[shttpd-general] Moving to code.google.com

[Sergey L. <va...@gm...>]

Dear SHTTPD users,

I plan to move the project to code.google.com. I believe Google provides
much better service than Sourceforge does.

As part of the plan, I think about changing the project name. SHTTPD has too
many consonants, I think of taking some animal's name. Suggestions are
welcome. Also, since code.google.com does not allow beerware license, I will
use MIT license. I hope this will not hurt anyone. Please speak up if it
does, and I will try to make an exception for us!

Next release will be on code.google.com. It will include threading model,
and API simplification.
Now UNIX version is ready (except SSI support) and passes the tests, I am
starting to work on Windows part. New Year 2009 is the expected release
date.

Sergey.

Re: [shttpd-general] vulnerability-bug when transferring large files

[Sergey L. <va...@gm...>]

Thanks for the report.
I will commit version 2 soon, I am working on it actively now. It uses
thread-per-connection model, and I am sure this bug will go away.

On Wed, Nov 26, 2008 at 3:47 PM, Antonio Aguilar
<ant...@de...>wrote:

> Hello all,
>
> While testing shttpd for transferring files, I think I may have found a
> vulnerability-bug in the standalone server.
>
> When using 'curl' to fetch a large file from shttpd, if I suddenly
> interrupt the transfer using CTRL+C, shttpd becomes unstable.
>
> When I interrupt curl I get a list of 'listening' messages (using _DEBUG
> mode)
>
> FD_SET(3) (listening)
> select: 9
> FD_SET(3) (listening)
> select: 9
> FD_SET(3) (listening)
> select: 9
> FD_SET(3) (listening)
> select: 9
> FD_SET(3) (listening)
> select: 9
> FD_SET(3) (listening)
> select: 9
>
> after this shttpd seems to get 'stuck' and accepts connections but
> doesn't serve them.
>
> Similar behaviour was triggered when using jigdo.
>
> Note that this problem doesn't happen when using wget or axel.
>
> My guess is that it has something to do with the 'resumed downloads'
> feature or curl/jigdo but I have not explored this in more detail.
>
> Could you please confirm you also get this behaviour, my system setup
> and how to duplicate the bug is listed below,
>
> Best regards,
>
> Antonio.
>
>
> This is my system setup:
>
> Linux Ubuntu 8.10, kernel 2.6.27-7-generic
> shttpd 1.42 (latest source)
> compiled with `LIBS="-ldl -lpthread" CFLAGS="-D_DEBUG" make unix`
> in this build, libssl seems to be enabled by default.
>
> These are the steps duplicate the vulnerability-bug:
>
> 1) run shttpd in standalone mode and configure -root to a folder where
> you have large file > 100Mb (e.g. a movie, iso image, etc.).
>
> $ sudo ./shttpd -ports 80 -root ./website/ (has movie.avi 700M file)
>
> Note: that shttpd will printout many of debug messages
>
> 2) use the curl client to download the file and interrupt curl after few
> seconds (CTRL+C)
>
> $ curl http://localhost/movie.avi > movie.avi
>
> or you can also use jigdo
>
> $ jigdo http://localhost/movie.avi
>
> (you should get something like this)
>
> $ curl http://localhost/movie.avi > movie.avi
>   % Total    % Received % Xferd  Average Speed   Time    Time     Time
>  Current
>                                  Dload  Upload   Total   Spent    Left
>  Speed
>   6  707M    6 43.8M    0     0  26.6M      0  0:00:26  0:00:01
> 0:00:25 26.7M^C
>
> (curl is interrupted - ^C)
>
> (check in shttpd console for debug messages)
>
> (try using wget or your web browser to view or download a page/file)
>
> $ wget http://localhost/movie.avi
> --2008-11-26 16:12:17--  http://localhost/movie.avi
> Resolving localhost... 127.0.0.1
> Connecting to localhost|127.0.0.1|:80... connected.
> HTTP request sent, awaiting response... ^C
>
> (connection hangs).
>
> -------------------------------------------------------------------------
> 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
> sht...@li...
> https://lists.sourceforge.net/lists/listinfo/shttpd-general
>

[shttpd-general] vulnerability-bug when transferring large files

[Antonio A. <ant...@de...>]

Hello all,

While testing shttpd for transferring files, I think I may have found a 
vulnerability-bug in the standalone server.

When using 'curl' to fetch a large file from shttpd, if I suddenly 
interrupt the transfer using CTRL+C, shttpd becomes unstable.

When I interrupt curl I get a list of 'listening' messages (using _DEBUG 
mode)

FD_SET(3) (listening)
select: 9
FD_SET(3) (listening)
select: 9
FD_SET(3) (listening)
select: 9
FD_SET(3) (listening)
select: 9
FD_SET(3) (listening)
select: 9
FD_SET(3) (listening)
select: 9

after this shttpd seems to get 'stuck' and accepts connections but 
doesn't serve them.

Similar behaviour was triggered when using jigdo.

Note that this problem doesn't happen when using wget or axel.

My guess is that it has something to do with the 'resumed downloads' 
feature or curl/jigdo but I have not explored this in more detail.

Could you please confirm you also get this behaviour, my system setup 
and how to duplicate the bug is listed below,

Best regards,

Antonio.


This is my system setup:

Linux Ubuntu 8.10, kernel 2.6.27-7-generic
shttpd 1.42 (latest source)
compiled with `LIBS="-ldl -lpthread" CFLAGS="-D_DEBUG" make unix`
in this build, libssl seems to be enabled by default.

These are the steps duplicate the vulnerability-bug:

1) run shttpd in standalone mode and configure -root to a folder where 
you have large file > 100Mb (e.g. a movie, iso image, etc.).

$ sudo ./shttpd -ports 80 -root ./website/ (has movie.avi 700M file)

Note: that shttpd will printout many of debug messages

2) use the curl client to download the file and interrupt curl after few 
seconds (CTRL+C)

$ curl http://localhost/movie.avi > movie.avi

or you can also use jigdo

$ jigdo http://localhost/movie.avi

(you should get something like this)

$ curl http://localhost/movie.avi > movie.avi
   % Total    % Received % Xferd  Average Speed   Time    Time     Time 
  Current
                                  Dload  Upload   Total   Spent    Left 
  Speed
   6  707M    6 43.8M    0     0  26.6M      0  0:00:26  0:00:01 
0:00:25 26.7M^C

(curl is interrupted - ^C)

(check in shttpd console for debug messages)

(try using wget or your web browser to view or download a page/file)

$ wget http://localhost/movie.avi
--2008-11-26 16:12:17--  http://localhost/movie.avi
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... ^C

(connection hangs).

Re: [shttpd-general] shttpd 1.42 read_stream errors crashing

[David L. <da...@sa...>]

OK, added 2 lines marked below 

 

      do_close = (c->ch.connection.v_vec.len >= vec.len 

      && !_shttpd_strncasecmp(vec.ptr,c->ch.connection.v_vec.ptr,vec.len)

            ) ||

          (c->major_version < 1 ||

          (c->major_version >= 1 && c->minor_version < 1));

 

      if (c->loc.content_len > 0)         // Added these lines to force connection

            do_close = 1;                 // to close if len > 0

 

I also tried commenting out _shttpd_set_nonblocking_mode() in shttpd_socketpair() as I saw some follow-ups about trying this as well.   It didn’t seem to make any difference.  Both the shttpd executable and the web browser are run on same machine.

 

In any event, modifying the do_close  provides a major improvement, but it does not fix the problem.   Without the patch, I get anywhere from 1-16 refreshes.  With the patch, I ranged from low of 1 to high of 4314 refreshes.  (But regardless, both read and write socket can fail).   

Here is dump of 941 iterations, then I ran it again immediately afterword and it only got one refresh.    Here is the full dump of the iteration that only ran through one cycle before losing the socket.

 

Is there a hack that can be added to just reestablish the socket if it closes and then just move on?   

 

(TAIL END OF RUN THAT LASTED 941 ITERATIONS)

decide_what_to_do: [/people-list.txt?_dc=1227620095607]

is_alias: aliases [/extjs=extjs,/images=images,/icons=icons,/data=root]

loc: 191 [HTTP/1.1 200 OK

Date: Tue, 25 Nov 2008 07:34:55 GMT

Last-Modified: Tue, 25 Nov 2008 07:33:18 GMT

Etag: "492bfe9e.3d"

Content-Type: text/plain

Content-Length: 61

Accept-Ranges: bytes

 

]

rem: 0 []

write_stream (1844 socket): written -1/191 bytes (errno 10054)

1844 (null) stopped. 0 of content data, 0 now in a buffer

wrndebugw --- socket closed, this is bad, unless program just started. ERRNO=10054,RemMethod=1

nIterations = 941

New instance that runs for just one iteration….  

 

C:\msdevstd\projects\VideoAgent\vc2005\Release>videoagent

shttpd_listen: added socket 1936

shttpd_listen: added socket 1936

shttpd_listen: added socket 1908

Started on ports(s) 4079,4080, serving HTML

FD_SET(1936) (listening)

FD_SET(1908) (listening)

192.168.1.155:4079 connected (socket 1848)

192.168.1.155:4079 connected (socket 1836)

0.0.0.0:4079 connected (socket 1824)

0.0.0.0:4079 connected (socket 1812)

192.168.1.155:4079 connected (socket 1800)

loc: 0 []

rem: 0 []

loc: 0 []

rem: 0 []

loc: 0 []

rem: 0 []

loc: 0 []

rem: 0 []

loc: 0 []

rem: 0 []

FD_SET(1936) (listening)

FD_SET(1908) (listening)

read_stream (1848 socket): read 496/16384/496 bytes (errno 0)

Conn 1848: parsing request: [GET /people-list.txt?_dc=1227620166970 HTTP/1.1

Accept: */*

Accept-Language: en-us

Referer: http://192.168.1.155:4079/index5.html

x-requested-with: XMLHttpRequest

UA-CPU: x86

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; InfoPath.

2; .NET CLR 3.5.21022; FDM; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

Host: 192.168.1.155:4079

Connection: Keep-Alive

 

]

parsing headers (len 447): [Accept: */*

Accept-Language: en-us

Referer: http://192.168.1.155:4079/index5.html

x-requested-with: XMLHttpRequest

UA-CPU: x86

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; InfoPath.

2; .NET CLR 3.5.21022; FDM; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

Host: 192.168.1.155:4079

Connection: Keep-Alive

 

]

decide_what_to_do: [/people-list.txt?_dc=1227620166970]

is_alias: aliases [/extjs=extjs,/images=images,/icons=icons,/data=root]

loc: 191 [HTTP/1.1 200 OK

Date: Tue, 25 Nov 2008 07:36:09 GMT

Last-Modified: Tue, 25 Nov 2008 07:36:08 GMT

Etag: "492bff48.3d"

Content-Type: text/plain

Content-Length: 61

Accept-Ranges: bytes

 

]

rem: 0 []

write_stream (1848 socket): written 191/191 bytes (errno 0)

1836 (null) stopped. 0 of content data, 0 now in a buffer

read_stream (1836 (null)): read 0/16384/0 bytes (errno 0)

loc: 0 []

rem: 0 []

Disconnecting 1836 ()

1824 (null) stopped. 0 of content data, 0 now in a buffer

read_stream (1824 (null)): read -1/16384/0 bytes (errno 10054)

debug --- socket closed, this is bad, unless program just started. ERRNO=10054,RemMethod=1

nIterations = 1

Re: [shttpd-general] shttpd 1.42 read_stream errors crashing

[Sergey L. <va...@gm...>]

Hi David! Could you disable keep-alive and see what happens, please?
        /* Keep the connection open only if we have Content-Length set */
 +     do_close = 1;

On Tue, Nov 25, 2008 at 4:04 AM, Henryla <he...@gm...> wrote:

> Hello,
>
> I also encountered the socket error problem in embedded system. (on a very
> busy system...)
> My solution is to remove the keep-alive feature and it runs well.
>
> This work around may solve this issue temporarily, but without
> 'keep-alive'. :)
>
> BR,
>
> Henry
>
>
>
>
> On Tue, Nov 25, 2008 at 8:06 AM, Sergey Lyubka <va...@gm...> wrote:
>
>> Maybe shttpd is leaking file descriptors?
>> I currently work on the next version of shttpd, which will use
>> thread-per-connection model, thus the code will be more simple. I am not
>> very active in fixing bugs because of that.
>> I'll try to search for good win32 profiler, that shows resource leaks, and
>> test shttpd against it.
>>
>>
>> On Mon, Nov 24, 2008 at 10:41 PM, David Lethe <da...@sa...> wrote:
>>
>>> I'm using the standard 1.42 version of shttpd and am getting errno 10054
>>> under windows repeatedly after an application runs for a while.
>>> Specifically in process_connection function, the call to read_stream
>>> fails with err #10054 because it can't read from the socket anymore.
>>>
>>> The only thing that is somewhat unusual is that the HTML is using extjs
>>> and the page is refreshing once a second, and there is quite a bit of
>>> javascript due to the extjs library.  But I've checked and there are no
>>> memory-related issues with the JavaScript (as far as I can tell) -- but
>>> I am going to retest with another web server, just to make sure in the
>>> interim.
>>>
>>> The problem can be reproduced on multiple PC's , all running XP, and it
>>> doesn't matter what O/S browser combination is used for the web browser.
>>>
>>> I have fiddled with the ctx_polling polling frequency, changed from
>>> 100ms to 100seconds, just to see if this makes any difference. It
>>> doesn't seem to make a difference.  Sometimes the app runs for 30 mins,
>>> sometimes 4-5 hours before the socket closes, and this happens on
>>> multiple machines.
>>>
>>> Below is the shttpd.conf file.  Nothing fancy going on, and I'm not
>>> doing any threading.
>>>
>>> # SHTTPD web server configuration file.
>>> # Lines starting with '#' and empty lines are ignored.
>>> # For detailed description, visit
>>> http://shttpd.sourceforge.net/shttpd.1.txt
>>>
>>> root            C:\msdevstd\projects\VideoAgent\vc2005\Release\HTML
>>> ports           4079,4080
>>> dir_list        no
>>> index_files     index.htm,index.html
>>> aliases
>>> /extjs=C:\msdevstd\projects\VideoAgent\vc2005\Release\extjs,/images=C:\m
>>> sdevstd\projects\VideoAgent\vc2005\Release\images,/icons=C:\msdevstd\pro
>>> jects\VideoAgent\vc2005\Release\icons,/data=root
>>>
>>> Any ideas, or suggestions on a fix?
>>>
>>> David
>>>
>>>
>>>
>>> -------------------------------------------------------------------------
>>> 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
>>> sht...@li...
>>> 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
>> sht...@li...
>> https://lists.sourceforge.net/lists/listinfo/shttpd-general
>>
>>
>

Re: [shttpd-general] shttpd 1.42 read_stream errors crashing

[Henryla <he...@gm...>]

Hello,

I also encountered the socket error problem in embedded system. (on a very
busy system...)
My solution is to remove the keep-alive feature and it runs well.

This work around may solve this issue temporarily, but without 'keep-alive'.
:)

BR,

Henry



On Tue, Nov 25, 2008 at 8:06 AM, Sergey Lyubka <va...@gm...> wrote:

> Maybe shttpd is leaking file descriptors?
> I currently work on the next version of shttpd, which will use
> thread-per-connection model, thus the code will be more simple. I am not
> very active in fixing bugs because of that.
> I'll try to search for good win32 profiler, that shows resource leaks, and
> test shttpd against it.
>
>
> On Mon, Nov 24, 2008 at 10:41 PM, David Lethe <da...@sa...> wrote:
>
>> I'm using the standard 1.42 version of shttpd and am getting errno 10054
>> under windows repeatedly after an application runs for a while.
>> Specifically in process_connection function, the call to read_stream
>> fails with err #10054 because it can't read from the socket anymore.
>>
>> The only thing that is somewhat unusual is that the HTML is using extjs
>> and the page is refreshing once a second, and there is quite a bit of
>> javascript due to the extjs library.  But I've checked and there are no
>> memory-related issues with the JavaScript (as far as I can tell) -- but
>> I am going to retest with another web server, just to make sure in the
>> interim.
>>
>> The problem can be reproduced on multiple PC's , all running XP, and it
>> doesn't matter what O/S browser combination is used for the web browser.
>>
>> I have fiddled with the ctx_polling polling frequency, changed from
>> 100ms to 100seconds, just to see if this makes any difference. It
>> doesn't seem to make a difference.  Sometimes the app runs for 30 mins,
>> sometimes 4-5 hours before the socket closes, and this happens on
>> multiple machines.
>>
>> Below is the shttpd.conf file.  Nothing fancy going on, and I'm not
>> doing any threading.
>>
>> # SHTTPD web server configuration file.
>> # Lines starting with '#' and empty lines are ignored.
>> # For detailed description, visit
>> http://shttpd.sourceforge.net/shttpd.1.txt
>>
>> root            C:\msdevstd\projects\VideoAgent\vc2005\Release\HTML
>> ports           4079,4080
>> dir_list        no
>> index_files     index.htm,index.html
>> aliases
>> /extjs=C:\msdevstd\projects\VideoAgent\vc2005\Release\extjs,/images=C:\m
>> sdevstd\projects\VideoAgent\vc2005\Release\images,/icons=C:\msdevstd\pro
>> jects\VideoAgent\vc2005\Release\icons,/data=root
>>
>> Any ideas, or suggestions on a fix?
>>
>> David
>>
>>
>>
>> -------------------------------------------------------------------------
>> 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
>> sht...@li...
>> 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
> sht...@li...
> https://lists.sourceforge.net/lists/listinfo/shttpd-general
>
>

Re: [shttpd-general] shttpd 1.42 read_stream errors crashing

[Sergey L. <va...@gm...>]

Maybe shttpd is leaking file descriptors?
I currently work on the next version of shttpd, which will use
thread-per-connection model, thus the code will be more simple. I am not
very active in fixing bugs because of that.
I'll try to search for good win32 profiler, that shows resource leaks, and
test shttpd against it.

On Mon, Nov 24, 2008 at 10:41 PM, David Lethe <da...@sa...> wrote:

> I'm using the standard 1.42 version of shttpd and am getting errno 10054
> under windows repeatedly after an application runs for a while.
> Specifically in process_connection function, the call to read_stream
> fails with err #10054 because it can't read from the socket anymore.
>
> The only thing that is somewhat unusual is that the HTML is using extjs
> and the page is refreshing once a second, and there is quite a bit of
> javascript due to the extjs library.  But I've checked and there are no
> memory-related issues with the JavaScript (as far as I can tell) -- but
> I am going to retest with another web server, just to make sure in the
> interim.
>
> The problem can be reproduced on multiple PC's , all running XP, and it
> doesn't matter what O/S browser combination is used for the web browser.
>
> I have fiddled with the ctx_polling polling frequency, changed from
> 100ms to 100seconds, just to see if this makes any difference. It
> doesn't seem to make a difference.  Sometimes the app runs for 30 mins,
> sometimes 4-5 hours before the socket closes, and this happens on
> multiple machines.
>
> Below is the shttpd.conf file.  Nothing fancy going on, and I'm not
> doing any threading.
>
> # SHTTPD web server configuration file.
> # Lines starting with '#' and empty lines are ignored.
> # For detailed description, visit
> http://shttpd.sourceforge.net/shttpd.1.txt
>
> root            C:\msdevstd\projects\VideoAgent\vc2005\Release\HTML
> ports           4079,4080
> dir_list        no
> index_files     index.htm,index.html
> aliases
> /extjs=C:\msdevstd\projects\VideoAgent\vc2005\Release\extjs,/images=C:\m
> sdevstd\projects\VideoAgent\vc2005\Release\images,/icons=C:\msdevstd\pro
> jects\VideoAgent\vc2005\Release\icons,/data=root
>
> Any ideas, or suggestions on a fix?
>
> David
>
>
>
> -------------------------------------------------------------------------
> 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
> sht...@li...
> https://lists.sourceforge.net/lists/listinfo/shttpd-general
>

[shttpd-general] shttpd 1.42 read_stream errors crashing

[David L. <da...@sa...>]

I'm using the standard 1.42 version of shttpd and am getting errno 10054
under windows repeatedly after an application runs for a while.
Specifically in process_connection function, the call to read_stream
fails with err #10054 because it can't read from the socket anymore.

The only thing that is somewhat unusual is that the HTML is using extjs
and the page is refreshing once a second, and there is quite a bit of
javascript due to the extjs library.  But I've checked and there are no
memory-related issues with the JavaScript (as far as I can tell) -- but
I am going to retest with another web server, just to make sure in the
interim.

The problem can be reproduced on multiple PC's , all running XP, and it
doesn't matter what O/S browser combination is used for the web browser.

I have fiddled with the ctx_polling polling frequency, changed from
100ms to 100seconds, just to see if this makes any difference. It
doesn't seem to make a difference.  Sometimes the app runs for 30 mins,
sometimes 4-5 hours before the socket closes, and this happens on
multiple machines.

Below is the shttpd.conf file.  Nothing fancy going on, and I'm not
doing any threading.

# SHTTPD web server configuration file.
# Lines starting with '#' and empty lines are ignored.
# For detailed description, visit
http://shttpd.sourceforge.net/shttpd.1.txt

root 		C:\msdevstd\projects\VideoAgent\vc2005\Release\HTML
ports           4079,4080
dir_list	no
index_files     index.htm,index.html
aliases
/extjs=C:\msdevstd\projects\VideoAgent\vc2005\Release\extjs,/images=C:\m
sdevstd\projects\VideoAgent\vc2005\Release\images,/icons=C:\msdevstd\pro
jects\VideoAgent\vc2005\Release\icons,/data=root

Any ideas, or suggestions on a fix?

David

Re: [shttpd-general] shttpd 1.42 read_stream errors crashing

[David L. <da...@sa...>]

> -----Original Message-----
> From: David Lethe
> Sent: Monday, November 24, 2008 4:42 PM
> To: 'sht...@li...'
> Subject: shttpd 1.42 read_stream errors crashing
> 
> I'm using the standard 1.42 version of shttpd and am getting errno
> 10054 under windows repeatedly after an application runs for a while.
> Specifically in process_connection function, the call to read_stream
> fails with err #10054 because it can't read from the socket anymore.
> 
> The only thing that is somewhat unusual is that the HTML is using
extjs
> and the page is refreshing once a second, and there is quite a bit of
> javascript due to the extjs library.  But I've checked and there are
no
> memory-related issues with the JavaScript (as far as I can tell) --
but
> I am going to retest with another web server, just to make sure in the
> interim.
> 
> The problem can be reproduced on multiple PC's , all running XP, and
it
> doesn't matter what O/S browser combination is used for the web
> browser.
> 
> I have fiddled with the ctx_polling polling frequency, changed from
> 100ms to 100seconds, just to see if this makes any difference. It
> doesn't seem to make a difference.  Sometimes the app runs for 30
mins,
> sometimes 4-5 hours before the socket closes, and this happens on
> multiple machines.
> 
> Below is the shttpd.conf file.  Nothing fancy going on, and I'm not
> doing any threading.
> 
> # SHTTPD web server configuration file.
> # Lines starting with '#' and empty lines are ignored.
> # For detailed description, visit
> http://shttpd.sourceforge.net/shttpd.1.txt
> 
> root 		C:\msdevstd\projects\VideoAgent\vc2005\Release\HTML
> ports           4079,4080
> dir_list	no
> index_files     index.htm,index.html
> aliases
>
/extjs=C:\msdevstd\projects\VideoAgent\vc2005\Release\extjs,/imag
>
es=C:\msdevstd\projects\VideoAgent\vc2005\Release\images,/icons=C:\msde
> vstd\projects\VideoAgent\vc2005\Release\icons,/data=root
> 
> Any ideas, or suggestions on a fix?
> 
> David
Forgot to send the rest .. 
I tried commenting out set_non_blocking_mode() calls from socketpair, as
suggested by Sergey on 2008-06-08, in regards to the SHTTPD cgi troubles
bug.   It did not resolve the problem.

Below is last part of the dump before the socket closed.
==============================================================
]
decide_what_to_do: [/people-list.txt?_dc=1227569175057]
is_alias: aliases [/extjs=extjs,/images=images,/icons=icons,/data=root]
open_auth_file: open(HTML/.htpasswd)
loc: 191 [HTTP/1.1 200 OK
Date: Mon, 24 Nov 2008 17:26:14 GMT
Last-Modified: Mon, 24 Nov 2008 17:22:47 GMT
Etag: "492b3747.3d"
Content-Type: text/plain
Content-Length: 61
Accept-Ranges: bytes

]
rem: 0 []
write_stream (1888 socket): written 191/191 bytes (errno 0)
loc: 0 []
rem: 0 []
read_stream (1888 file): read 61/61/61 bytes (errno 0)
1888 (null) stopped. 61 of content data, 61 now in a buffer
write_stream (1888 socket): written 61/61 bytes (errno 0)
Disconnecting 1888 (Keep-Alive)
read_stream (1888 socket): read 488/16384/488 bytes (errno 0)
Conn 1888: parsing request: [GET /people-list.txt?_dc=1227569176159
HTTP/1.1
Accept: */*
Accept-Language: en-us
Referer: http://localhost:4079/index5.html
x-requested-with: XMLHttpRequest
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR
3.0.04506.648; InfoPath.
2; .NET CLR 3.5.21022; FDM; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Host: localhost:4079
Connection: Keep-Alive

]
parsing headers (len 439): [Accept: */*
Accept-Language: en-us
Referer: http://localhost:4079/index5.html
x-requested-with: XMLHttpRequest
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR
3.0.04506.648; InfoPath.
2; .NET CLR 3.5.21022; FDM; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Host: localhost:4079
Connection: Keep-Alive

]
decide_what_to_do: [/people-list.txt?_dc=1227569176159]
is_alias: aliases [/extjs=extjs,/images=images,/icons=icons,/data=root]
open_auth_file: open(HTML/.htpasswd)
loc: 191 [HTTP/1.1 200 OK
Date: Mon, 24 Nov 2008 17:26:15 GMT
Last-Modified: Mon, 24 Nov 2008 17:22:47 GMT
Etag: "492b3747.3d"
Content-Type: text/plain
Content-Length: 61
Accept-Ranges: bytes

]
rem: 0 []
write_stream (1888 socket): written 191/191 bytes (errno 0)
loc: 0 []
rem: 0 []
read_stream (1888 file): read 61/61/61 bytes (errno 0)
1888 (null) stopped. 61 of content data, 61 now in a buffer
write_stream (1888 socket): written 61/61 bytes (errno 0)
Disconnecting 1888 (Keep-Alive)
1888 (null) stopped. 0 of content data, 0 now in a buffer
read_stream (1888 (null)): read -1/16384/0 bytes (errno 10054)

--- socket closed, this is bad, unless program just started.
ERRNO=10054,RemMethod=1

[shttpd-general] 100-continue urgent fix

[Christian <mai...@ya...>]

I reread the changes made to `shttpd' and I realized that there is an 
error in reading data from the client.

I corrected the mistake and I created 2 new patch to be applied to 
amended code (the code amended
by the previous patch).  To apply patches simple copy files into source 
directory, cd to it and type:

    patch -u < ./shttpd.c.patch
    patch -u < ./defs.h.patch

However I think the support is not complete and need some tests.

Thank's.

Christian.

[shttpd-general] 100-continue support

[Christian <mai...@ya...>]

I work on shttpd to make it handle the "100-continue" HTTP Header.
I work on last source, generated from the CVS checkout.
Whit this mail there are 3 patches.
To apply simple copy the files to the "src" directory, go into it and type:

    patch -u -p2 < ./defs.h.patch
    patch -u -p2 < ./shttpd.c.patch
    patch -u -p2 < ./cgi.c.patch

Thank's to Leslie P. Polzer, shttpd hacker's and all people wich work on 
Free Software!

Christian.

[shttpd-general] How to insert a module in shttpd

[Martin w. <wu...@gm...>]

Hi guys , 

I'm sorry for my noise . I just begin to use and trace the codes of this good webserver.
I want to insert a module can handler the content datas in http packets. Subsequently , i'll change fill my datas required to send out in http packet. I don't know how to do this. I need your help to accelerate my process. Do move forward with your good advice.
Any help is appreciate!


2008-10-24 



Martin woo 

Re: [shttpd-general] Multipart Form data processing

[Sergey L. <va...@gm...>]

shttpd does not decode POST content, so you need to do it yourself.

On Tue, Oct 21, 2008 at 1:21 PM, <ma...@re...> wrote:

> Good afternoon,
>
> I need to write a web page that uploads a file using the SHTTPD server. I
> am using it in the embedded mode (no CGI, etc..) and I was wondering is
> anyone has any useful suggestions for how to handle the
> multipart/form-data data that is passed back in the POST.
>
>
> Thanks in advance
> Mark Retallack
>
> PS. Thankyou for creating a very useful and simple HTTP server.
>
>
>
> -------------------------------------------------------------------------
> 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
> sht...@li...
> https://lists.sourceforge.net/lists/listinfo/shttpd-general
>