Please release version 2.9

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use Mongoose for awhile
2. Notice pointer fault crash at offset 0x000031d4
3. Notice that this has been fixed in version 2.9
4. Notice that later on there can be instabilities in other applications (crash 
in Avira rootkit detector avipbb)

Note: any time there is a bug fix for a crash or hang, it should be released 
immediately. Otherwise, Mongoose could get a bad reputation.

Please compilre version 2.9, at least for Windows, and release.

What is the expected output? What do you see instead?

System Application Log shows error entry, event ID 1000.

Please use labels and text to provide additional information.

None

Original issue reported on code.google.com by googl...@springtimesoftware.com on 27 Aug 2010 at 2:23

[GoogleCodeExporter]

Yeah, I am about to release 2.9.
Unfortunately, I am unable to test it properly under Windows. I am thinking on 
how can I set up good regression test.

Original comment by valenok on 27 Aug 2010 at 9:17

• Changed state: Accepted

[GoogleCodeExporter]

I'm not sure what a good regression test should cover. Might be too complicated 
for me to do if every feature must be tested. But you can give me an advance 
copy of 2.9 and at least I can check that it no longer crashes.

I did some editing of the two pages on Wikipedia that mention Mongoose. The 
article we wrote on Mongoose has been deleted, so I added references mentioning 
this and giving a link to Google Code.

All information allowing easy comparison of the various small webservers has 
been deleted from the two comparison articles. I proposed a solution, but it 
may or may not be accepted by other editors.

The article that was deleted was well-written; it listed all the advantages of 
using Mongoose. But that's how it goes at WP: many really good articles are 
deleted all the time. If we get a magazine review of Mongoose, a software 
award, an article describing how it is being used in a real project, or 
something similar, we can request restoration of the article based on the 
"reliable source" and "notability" policies.

Original comment by googl...@springtimesoftware.com on 27 Aug 2010 at 9:42

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

By the way, do you have any ideas about how two local webservers (Mongoose and 
Apache) can both listen on the same port (80) for local requests but use 
different loopback or LAN IP addresses so that web browsers can select them 
easily, without having to specify a port number? For example, I'd like the 
browser address http://localhost to use Apache to show the Apache root page, 
and http://mongoose to use Mongoose to show the Mongoose root page. I almost 
have it working (Mongoose works but not Apache), but I'm missing some key 
insight. I'm using the HOSTS file to map localhost to 127.0.0.1 and mongoose to 
127.1.1.1.

There are lots of uses for this, such as testing both servers using complicated 
CGI and other features, or for testing while porting an Intranet application 
from one server to another (sometimes there is a big reliance on advanced 
Apache or IIS features that can be eliminated so the app works on Mongoose).

Original comment by googl...@springtimesoftware.com on 27 Aug 2010 at 9:54

[GoogleCodeExporter]

You can try out today's binary at 
http://silversoft.net/~devnull/tmp/mongoose.27Aug2010.exe

Original comment by valenok on 27 Aug 2010 at 11:25

[GoogleCodeExporter]

Thanks for editing on Wikipedia!
I guess, it would be worth mentioning a LinuxJournal article, and give a 
reference.
Probably that sort of things are required as "reliable sources".

Original comment by valenok on 27 Aug 2010 at 11:29

[GoogleCodeExporter]

Yes, it's worth a try as soon as we have at least three articles in three 
journals. One is not enough to prove 'notability'. Wikipedia is really weird.

Original comment by googl...@springtimesoftware.com on 27 Aug 2010 at 11:35

[GoogleCodeExporter]

When I run this version of mongoose.exe, it immediately closes. I'm not sure 
how my environment could be that different from yours. I didn't (and still 
don't) have this problem with 2.8, so there must be a problem with this 
version. I don't know how to debug standalone executables, sorry.

Original comment by googl...@springtimesoftware.com on 28 Aug 2010 at 1:20

[GoogleCodeExporter]

I think I got both Mongoose and Apache running on one machine, sharing port 80 
for simplicity in Web addresses. Here's how to do it:

In Apache config file (Apache/conf/httpd.conf):

Listen 127.0.0.1:80
ServerName localhost
UseCanonicalName On

In Mongoose config file:

ports           80
acl             -0.0.0.0/0,+127.1.1.1
cgi_env         SERVER_NAME=mongoose

In HOSTS file (default local DNS):

127.0.0.1 localhost
127.1.1.1 mongoose

After this gets tested (http://mongoose/ shows the Mongoose root page and 
http://localhost/ shows the Apache root page), it could be added to the wiki or 
the Mongoose manual. And this example needs to be modified to work under Unix 
and other environments.

Original comment by googl...@springtimesoftware.com on 28 Aug 2010 at 2:52

[GoogleCodeExporter]

I've been running Mongoose off and on using your special build for the last day 
or two, and it hasn't crashed. I would say, go ahead and release it. Crashes 
won't be good publicity for Mongoose, which is otherwise very well debugged.

It's such a relief not to have to install Apache (which, although having a 
smaller kernel than Mongoose, has a total directory size of around 10 MB, and 
is much more difficult to configure) on my tiny computer and yet to continue my 
Web programming work there. Thanks, Sergey!

Original comment by googl...@springtimesoftware.com on 29 Aug 2010 at 9:31

[GoogleCodeExporter]

Welcome. I am about to release it, just cleaning up bits and pieces.
Sometimes this week, hopefully.

I was thinking quite hard about the best backward-compatible API, and imagine 
what? I've changed the API, together with the configuration option names. I 
made them bit longer, but more descriptive. Like, -root option became 
-document_root, -ports option became -listening_ports, etcetera.

Also, embedding API has also changed, which probably doesn't concern you much.

I hope that the naming change would not be very frustrating (I understand it is 
always annoying).

Original comment by valenok on 29 Aug 2010 at 10:15

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Agree with that.
The reason for longer, more descriptive names comes from an embedded interface.
Maybe for standalone binary, the right way is to have one-letter options.
E.g. "mongoose -r /var/www -p 8080". I'll think about that.

Original comment by valenok on 30 Aug 2010 at 8:14

[GoogleCodeExporter]

I've just pushed a change that allows short option names in mongoose:
mongoose -r /var/www -p 8080

Original comment by valenok on 30 Aug 2010 at 12:12

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

You said, "The reason for longer, more descriptive names comes from an embedded 
interface." But that doesn't make sense to me. People who create embedded 
applications know what they are doing, so they neither need nor want longer 
names.

Am I misunderstanding something?

Considering option names in general, one could have "r", "root", or 
"root_document". Here are my thoughts:

* The ideal length and "feel" of an option name depends not on "the right way" 
but on specific users. There will be no general agreement which is best.

* Personally, I don't care, since I only want to set up the configuration once. 
I think that might be true of the majority of advanced users.

* However, newcomers probably would benefit from a tradeoff. "r" is too short 
(example: Unix short command names are difficult for newcomers to Unix); "root" 
is nice because it is an English word; "root_document" is long without being 
any more helpful than "root"--the only way to understand config directives is 
to read the Help.

* I believe that config directives don't need multiple lengths (both "r" and 
"root", for example). It produces confusion rather than supporting personal 
preference.

In summary: newcomers appreciate a short word in their native language; 
advanced users, including embedded systems programmers, don't care about length 
or "feel" of directives, so long as they don't change.

I understand your desire to "get it right" early in the project, but there will 
always be the possibility you will change your mind about directive/option 
names. For that reason, and because it makes work for programmers when names 
change, I believe that keeping the names the same forever is more useful than 
picking the right names.

Of course, if Mongoose were in Alpha test or before, this would not apply, 
since there would be no real users. But it's really in Beta test (or later) 
now, so my last paragraph applies.

Original comment by googl...@springtimesoftware.com on 30 Aug 2010 at 2:55

[GoogleCodeExporter]

Short names are for command line use.
Long names are for config files and for embedded use.
Why config files and embedded code need long names? For readability. If a 
person reads Mongoose config file, I'd rather expect him/her to see
"listening_ports 8080,8081"
rather than
"p 8080,8081"

Mongoose will support both forms.

Original comment by valenok on 30 Aug 2010 at 2:59

[GoogleCodeExporter]

That makes good sense.

Original comment by googl...@springtimesoftware.com on 30 Aug 2010 at 7:53

[GoogleCodeExporter]

Issue 166 has been merged into this issue.

Original comment by valenok on 31 Aug 2010 at 6:48

[GoogleCodeExporter]

Please see issue 166, which apparently has NOT been merged correctly, for 
additional information.

I am using mongoose for real development on Windows, so I need a version that 
works.

Original comment by googl...@springtimesoftware.com on 31 Aug 2010 at 7:00

[GoogleCodeExporter]

Update Collision
What happened?

While you were viewing or updating issue 166, another user submitted an update 
to it. That user's update has already taken effect. Your update cannot be saved 
because your changes could overwrite the other user's changes.

Note: if you have been viewing and updating issue 166 in multiple browser 
windows or tabs, it is possible that the "other user" is actually yourself.
Your options:

    * Start over: view the up-to-date issue 166 and consider making your changes again.

----

I'm not sure you can see my latest suggestions. Probably it doesn't matter. I'm 
sure you will release an updated Manual when you have time. Until then, I'll 
guess at the new config file format.

Original comment by googl...@springtimesoftware.com on 1 Sep 2010 at 1:32

[GoogleCodeExporter]

1. I've looked in the latest Manual (2.8) and I cannot find any information 
about error handling. When I open a nonexistent page, I just get a fixed 404 
message. I want to provide my own message, which will tell me the path of the 
page.

2. I want to open all files via PHP, regardless of file extension or contents. 
This is easy to do in Apache .htaccess files, but I'm not sure what to do in 
mongoose config files.

3. Due to time pressure, I've read through all the 2.8 code quickly, but 
haven't had the time to figure out how to run Visual C++ version 6 (not VC 
Express, because I don't want to install the giant .NET CLR on either of my 
computers) with a makefile and the right libraries. If you know how, please 
just tell me. With the help of the VC IDE, I might make more progress in 
understanding how mongoose works so I can add features like 1 and 2 above, if 
they're missing.

Original comment by googl...@springtimesoftware.com on 1 Sep 2010 at 1:44

[GoogleCodeExporter]

I experimented and found out how to make a file with no extension be handled by 
an interpreter:

In the config file, put

cgi_interp      php-cgi.exe
cgi_ext         php,,

This makes php the only interpreter, then makes .php and . the cgi extensions. 
I didn't try ",," but I bet that would work, too.

Original comment by googl...@springtimesoftware.com on 1 Sep 2010 at 4:00

[GoogleCodeExporter]

Original comment by valenok on 3 Sep 2010 at 4:02

• Changed state: Done