headers
Michiel Boland | 4 Nov 2006 21:24
Gravatar

Re: Patch: allow /./ and /../ in URL paths

Hi.

I fiddled a bit with your patch, and it is now more or less in the new 
beta. (1.6b7), although the implemtation is a bit different.

I took the liberty of slightly changing the semantics because I want to be 
able to back-port this to 1.5 without breaking existing configurations.

To this end, the /./ /../ (and //) smashing must be explicitly enabled in 
the configuration file via the SanitizePath directive. If you do not set 
this, mathopd will treat URLs with /./ etc as an error.

Also URLs that end with /. and /.. are not allowed. (As they were with the 
original patch.) It could be argued that one should make some attempt to 
'fix' these too, but that would be a bit messy. Perhaps someone has any 
more thoughts to this?

If no problems turn up I will probably release a new 1.5 version sometime 
next week.

Cheers
Michiel
Permalink | Reply | 0 comments |
headers
Dmitry | 16 Nov 2006 16:20
Picon

Re: Logging and analysing

 On Monday 03 April 2006 17:50, Juergen Daubert wrote:
> On Mon, Apr 03, 2006 at 09:11:28AM +0200, J.Paechnatz wrote:
> > hello!
> >
> > I want to analyze the access.log of mathopd. How could I do this? I
> > checked the awk and perl script from the mathopd homepage, but I
> > didn't managed to get any output?! What log analyzer did you use after
> > putting the log in the right format?
>
> There's a recipe [1] for using analog as an logfile analyzer in the
> mathopd wiki. Would be nice if someone else could add similar pages for
> other analyzer.
>
> HTH
> Juergen
>
> [1] http://www.mathopd.org/wiki?Analog

Hello, 

I wonder how do you get "BytesWritten" from the cgi script? I always get 
zero bytes in mathopd log. Does this feature exist in newer versions of 
mathopd? I need it so much.

--

-- 
vdb
Permalink | Reply | 1 comment |
headers
Michiel Boland | 16 Nov 2006 20:28
Gravatar

Re: Logging and analysing

> Hello,
>
> I wonder how do you get "BytesWritten" from the cgi script? I always get
> zero bytes in mathopd log. Does this feature exist in newer versions of
> mathopd? I need it so much.

Mathopd 1.5 computes BytesWritten more or less correctly, also for CGI 
scripts. Versions 1.4 and earlier always put zero (or '-')

Cheers
Michiel
Permalink | Reply | 0 comments |
headers
Peter L. Mogan | 20 Nov 2006 05:41
Picon
Favicon

Building 64-bit mathopd on SUN UltraSPARC platforms?

Hello,

Heeding the warnings given in
http://www.mathopd.org/wiki?SolarisStdio 
"SolarisSTDIO", after using a 32 bit mathopd build for
a while, I decided to attempt to build a 64 bit
version
using the SUN Studio 11 C compiler with patch
120760-06.

More host/OS info:

$ uname -a
SunOS teaball 5.9 Generic_118558-28 sun4u sparc
SUNW,UltraAX-i2

Build result:

# make
/opt/SUNWspro/bin/cc -c -Xa -fast -native -xstrconst
-mt -xarch=v9 -xcache=16/32/1:256/64/4 -xchip=ultra2e
-DNEED_INET_ATON -DHAVE_CRYPT_H base64.c -o base64.o
/opt/SUNWspro/bin/cc -c -Xa -fast -native -xstrconst
-mt -xarch=v9 -xcache=16/32/1:256/64/4 -xchip=ultra2e
-DNEED_INET_ATON -DHAVE_CRYPT_H cgi.c -o cgi.o
/opt/SUNWspro/bin/cc -c -Xa -fast -native -xstrconst
-mt -xarch=v9 -xcache=16/32/1:256/64/4 -xchip=ultra2e
-DNEED_INET_ATON -DHAVE_CRYPT_H config.c -o config.o
/opt/SUNWspro/bin/cc -c -Xa -fast -native -xstrconst
-mt -xarch=v9 -xcache=16/32/1:256/64/4 -xchip=ultra2e
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michiel Boland | 20 Nov 2006 21:52
Gravatar

Re: Building 64-bit mathopd on SUN UltraSPARC platforms?

> /opt/SUNWspro/bin/cc -c -Xa -fast -native -xstrconst
> -mt -xarch=v9 -xcache=16/32/1:256/64/4 -xchip=ultra2e
> -DNEED_INET_ATON -DHAVE_CRYPT_H stub.c -o stub.o
> /opt/SUNWspro/bin/cc -R/usr/local/lib -s -o mathopd
> base64.o cgi.o config.o core.o dump.o imap.o log.o
> main.o  redirect.o request.o util.o stub.o
> -L/usr/lib/sparcv9 -lsocket -lnsl
> ld: fatal: file base64.o: wrong ELF class: ELFCLASS64

You need to add -xarch=v9 to LDFLAGS as well as CFLAGS.

HTH
Cheers
Michiel
Permalink | Reply | 0 comments |
headers
Peter L. Mogan | 20 Nov 2006 22:50
Picon
Favicon

Passing though unsupported HTTP methods instead of returning a 501 Not Implemented?

Hello,

We are testing out mathopd to see if we can use it to
run a FastCGI application (using spawn-fcgi, cgi-fcgi,
and PHP 5.1.6).

We originally planned to use lighttpd, but lighttpd
has a bug on the 100-Continue Status handling, which
hinders our application's ability to interact with
some clients.  

Looking further into the requst.c, I saw the
following:

static const char m_get[] =                     "GET";
static const char m_head[] =                   
"HEAD";
static const char m_post[] =                   
"POST";

As far as I could tell, there isn't an existing way to
pass through any unsupported HTTP methods, e.g. DELETE
to either a CGI or a FastCGI process.  In the function
static int process_headers(struct request *r), the
following block is very clear in this regard:

        if (strcmp(s, m_get) == 0)
                r->method = M_GET;
        else {
                if (strcmp(s, m_head) == 0)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Michiel Boland | 20 Nov 2006 23:06
Gravatar

Re: Passing though unsupported HTTP methods instead of returning a 501 Not Implemented?

> I must say the request.c is really a piece of cleanly
> written code. We are tempted to patch it so we can
> toggle it to pass through HTTP methods that don't have
> built-in support. But before we embark such an
> endeavor, we would like to hear people's comments
> first, especially, are we re-inventing the wheel?

Sounds interesting. To my knowledge noone has attempted this yet.

Cheers
Michiel
Permalink | Reply | 2 comments |
headers
Peter L. Mogan | 20 Nov 2006 23:27
Picon
Favicon

Re: Passing though unsupported HTTP methods instead of returning a 501 Not Implemented?

Hello Michael,

Thanks for your comments.  Besides the request.c in
the  mathopd distribution, I think I better carefully
review the cgi-fcgi bridge codes to see if it is a
potential stumbling block. So far I have only built
and used it.

By the way, creating a FastCGI is in your list of
planned or wished features
<http://www.mathopd.org/wiki?Development>.   If we do
go ahead and create a patch, will we be conflicting
with what you plan to do?

BTW, based on our experience, lighttpd's mod_fastcgi
passes through all unknown HTTP methods to spawn
FastCGI processes. 

Thanks,

--Peter

--- Michiel Boland <michiel <at> boland.org> wrote:

[...]
> 
> Sounds interesting. To my knowledge noone has
> attempted this yet.
> 
> Cheers
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michiel Boland | 21 Nov 2006 09:44
Gravatar

Re: Passing though unsupported HTTP methods instead of returning a 501 Not Implemented?

> By the way, creating a FastCGI is in your list of
> planned or wished features
> <http://www.mathopd.org/wiki?Development>.   If we do
> go ahead and create a patch, will we be conflicting
> with what you plan to do?

To be honest I haven't really begun, apart from writing a spawn-fcgi
lookalike to get a feeling of how things work. So there is not anything to
conflict with yet. :)
Permalink | Reply | 0 comments |
headers
Peter Pentchev | 26 Nov 2006 12:39
Gravatar

Licensing of the utilities?

Hi,

I'm thinking of packaging the dir_cgi.c and mattoclf utilities.
The dir_cgi source has a three-clause BSD license at the top; however,
the mattoclf awk and Perl scripts do not have any kind of copyright or
license information.  I assume the awk script was written by Michiel
Boland, and the Perl script by Peter Marelas, but this still leaves open
the question of what licensing conditions are they distributed under :)

G'luck,
Peter

--

-- 
Peter Pentchev	roam <at> ringlet.net    roam <at> cnsys.bg    roam <at> FreeBSD.org
PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
This sentence contradicts itself - or rather - well, no, actually it doesn't!
Permalink | Reply | 1 comment |

Gmane