[modperl 1.27] Problem regarding Perl*Handler and the HTTP request line

[co...@uhome.net]

Hi all

Apologise if I have posted to the wrong list.
I am quite new to the Perl*Handlers. I am wondering if it is possible to write a handler which parses the very first header line, say..

> telnet localhost http
Trying 127.0.0.1
Connected to localhost.
Escape character is '^]'

[C] THIS_IS_NOT_A_USUAL_HTTP_HEADER\r\n
[S] YOUR_REQUEST_IS_UNDERSTOOD,_SEND_MORE_DETAIL\r\n
[C] Other: non-usual-http-headers-here\r\n
[S] balbalbal..closing connection\r\n
Connection closed by remote host.

where the line followed by [C] stands for the line sent by the client, and the line followed by [S] is the line sent by some perl module.

I would like to have the other GET/POST requests being processed like any other server does (i.e. if the request line is a usual GET/POST line, the handler bypasses it, otherwise the handler will make apache 'sends' the request to another perl module that knows how to handle this request).

I would like to know if this is possible? Thanks in advance.


Michael

Re: [modperl 1.27] Problem regarding Perl*Handler and the HTTPrequest line

[Stas Bekman <st...@stason.org>]

>>in Apache/mod_perl 2.0, you can write an input filter that _does_ allow
> 
> you
> 
>>do parse the Request Line yourself.  then again, you can write a protocol
>>handler for any protocol you can dream up, so there's no reason to mess with HTTP :)

Actually in 2.0 you can even implement this in a HeaderParser handler. 
Here is such an example:
http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlHeaderParserHandler

Here is an example of the input filter that modifies the request headers 
(as suggested by Geoff):
http://perl.apache.org/docs/2.0/user/handlers/filters.html#Connection_Input_Filters


__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: [modperl 1.27] Problem regarding Perl*Handler and the HTTPrequest line

[co...@uhome.net]

> if my 'new http method' you mean something other that GET, POST, PUT, etc
> then no, you cannot (in Apache 1.3, at least).

yea. you got exactly what I mean!! :D
I want to put this non HTTP thing together with some other Apache::Registry
scripts on the same port 80 with modperl 1.27 and Apache 1.3.
The problem was that I could not find any clues in the 1.3 Guide (sorry I am
quite new to how Apache process a request).

>
> just about the only thing you cannot do with mod_perl is parse the Request
> Line - that is handled by Apache before the request cycle starts.  so
Apache
> will intercept the requests before the PerlPostReadRequestHandler runs,
> similar to the way it intercepts HTTP/1.1 requests without a Host header.
>
> in Apache/mod_perl 2.0, you can write an input filter that _does_ allow
you
> do parse the Request Line yourself.  then again, you can write a protocol
> handler for any protocol you can dream up, so there's no reason to mess
with
> HTTP :)

Thanks!! I got it now =)

P.S.: wish you all a merry christmas! :D

Re: [modperl 1.27] Problem regarding Perl*Handler and the HTTPrequest line

[Geoffrey Young <ge...@modperlcookbook.org>]

> I was wondering if it
> is
> possible to write a handler to handle a 'new http method', because I could
> not
> find any hint in the user guide. :)

if my 'new http method' you mean something other that GET, POST, PUT, etc 
then no, you cannot (in Apache 1.3, at least).

just about the only thing you cannot do with mod_perl is parse the Request 
Line - that is handled by Apache before the request cycle starts.  so Apache 
will intercept the requests before the PerlPostReadRequestHandler runs, 
similar to the way it intercepts HTTP/1.1 requests without a Host header.

in Apache/mod_perl 2.0, you can write an input filter that _does_ allow you 
do parse the Request Line yourself.  then again, you can write a protocol 
handler for any protocol you can dream up, so there's no reason to mess with 
HTTP :)

--Geoff

Re: [modperl 1.27] Problem regarding Perl*Handler and the HTTPrequest line

[Rodney Broom <mo...@rbroom.com>]

From: <co...@uhome.net>


> In fact I would like to write some little scripts
> to talk with the internals of Apache over port 80...

By "the internals", do you mean asking Apache about what it's doing and sending it new directives?

If all you need to do is catch particular requests, then Nick Tonkin has the idea. Let us know specifically what you want to get done, that will help in the answers.


---
Rodney Broom
President, R.Broom Consulting
http://www.rbroom.com/

Re: [modperl 1.27] Problem regarding Perl*Handler and the HTTPrequest line

[co...@uhome.net]

>> where the line followed by [C] stands for the line sent by the client,
>> and the line followed by [S] is the line sent by some perl module.
>
> It sounds to me as though you want to use Apache as a network service
> framework. Not a bad idea, but Apache already stands on a set protocol.
> Is this right, or do you actually want to run Apache as a web server on
port
> 80 AND have this non-HTTP thing going on at the same time from the same
port?

Thanks for your prompt response. In fact I would like to write some little
scripts
to talk with the internals of Apache over port 80, and I was wondering if it
is
possible to write a handler to handle a 'new http method', because I could
not
find any hint in the user guide. :)

Re: [modperl 1.27] Problem regarding Perl*Handler and the HTTPrequest line

[Rodney Broom <mo...@rbroom.com>]

> On Tue, 24 Dec 2002 corn@uhome.net wrote:

> I am wondering if it is possible to write a handler
> which parses the very first header line, say..

No, it's not possible. (Unless I'm really missing something)



> where the line followed by [C] stands for the line sent by the client,
> and the line followed by [S] is the line sent by some perl module.

It sounds to me as though you want to use Apache as a network service framework. Not a bad idea, but Apache already stands on a set protocol. Is this right, or do you actually want to run Apache as a web server on port 80 AND have this non-HTTP thing going on at the same time from the same port?



---
Rodney Broom
President, R.Broom Consulting
http://www.rbroom.com/

Re: [modperl 1.27] Problem regarding Perl*Handler and the HTTP request line

[Nick Tonkin <ni...@rlnt.net>]

On Tue, 24 Dec 2002 corn@uhome.net wrote:

> Hi all
> 
> Apologise if I have posted to the wrong list. I am quite new to the
> Perl*Handlers. I am wondering if it is possible to write a handler
> which parses the very first header line, say..
> 
> > telnet localhost http
> Trying 127.0.0.1
> Connected to localhost.
> Escape character is '^]'
> 
> [C] THIS_IS_NOT_A_USUAL_HTTP_HEADER\r\n
> [S] YOUR_REQUEST_IS_UNDERSTOOD,_SEND_MORE_DETAIL\r\n
> [C] Other: non-usual-http-headers-here\r\n
> [S] balbalbal..closing connection\r\n
> Connection closed by remote host.
> 
> where the line followed by [C] stands for the line sent by the client,
> and the line followed by [S] is the line sent by some perl module.
> 
> I would like to have the other GET/POST requests being processed like
> any other server does (i.e. if the request line is a usual GET/POST
> line, the handler bypasses it, otherwise the handler will make apache
> 'sends' the request to another perl module that knows how to handle
> this request).

If all you want to do is handle certain requests in a special manner, and
you are able to have control over the requests, why do you not use a
simpler scheme, such as directing them to a different port, or, better
yet, a different URI? 

If you are getting the requests from a browser it will be difficult anyway
to add custom headers, I think. But if you can control the request you can
easily have 

http://your.server.com/path/to/resource/special
http://your.server.com/path/to/resource

or something similar, and have a handler that handles everything in that
path, returning DECLINED if it doesn't match the URI you are looking for
(you don't need two handlers for this).

Hope this helps,

- nick