Hi folks.
Thanks all for your patience on this one, but I found the answer myself when I
looked more carefully at the documentation for CGI.pm:
-------------------------------------------------------------------------------
HANDLING NON-URLENCODED ARGUMENTS
If POSTed data is not of type application/x-www-form-urlencoded or
multipart/form-data, then the POSTed data will not be processed, but
instead be returned as-is in a parameter named POSTDATA. To retrieve it,
use code like this:
my $data = $query->param('POSTDATA');
-------------------------------------------------------------------------------
Apologies for not spotting this before I bothered you all!
Cheers, Jon.
-----Original Message-----
From: Jon Perkin [mailto:[email protected]]
Sent: 21 January 2010 09:27
To: [email protected]
Subject: Re: [Mason] Direct access to the request content
Hi Joe/Hans/MK.
Thanks for the suggestion of building my own server, but I strongly disagree
with the idea that HTTP/Apache/etc. is the wrong solution for me.
On the contrary, I'm building a site that will serve pages in an XML-derived
format, and that will require those pages to be constructed on-the-fly from
programmatic components mixing XML and (perl?) code in some sort of template
mechanism. Pages will contain references to assets such as images that come in
a variety of content types (some stored as static files and some need to be
generated on-the-fly), and will contain links to other pages. I'll need
facilities such as cookies, session management, and a TLS-secured version of
the protocol for certain pages. And I'll need it all served up by a
tried-and-tested server implementation that is robust and can be scaled to cope
with tens of millions of clients.
In other words, what I'm doing is *exactly* what HTTP, Apache, mod_perl & Mason
were designed for. None of those technologies care that my pages aren't in HTML
format, or even that for efficiency I want a handful of my pages to receive
unmodified serialised binary from my client platform as a non-standard HTTP
request body. It's still standard HTTP and if I designed my own protocol
instead it would have to look very much like HTTP.
Would anyone like to answer my original question, rather than questioning my
motives:
What's the best way to access the raw request body content from within a Mason
component?
Cheers, Jon.
-----Original Message-----
From: Joe Pepersack [mailto:[email protected]]
Sent: 20 January 2010 14:45
To: Jon Perkin
Cc: [email protected]
Subject: Re: [Mason] Direct access to the request content
The obvious question (to me) is if you're not making standard HTTP
requests and not serving HTML, why use Apache at all? You might be better
off writing your own custom server.
Refer to chapters 17 and 18 of the Perl Cookbook (especially example
17.5), as well as example 19.6 in chapter 19.
> Hi all.
>
> I'm working on a rather unusual web site in that the client software isn't
> actually a web browser and doesn't understand HTML! I'm planning to use
> Mason on Apache2/mod_perl2, which I've used on other projects with great
> success.
>
> However, the client will be making requests to the server with
> non-standard request bodies, so I'd like to know what is the best way in
> Mason on mod_perl2 to access the raw content of the request. It isn't
> obvious to me from either Mason or mod_perl2 documentation.
>
> I'm currently using CGI.pm, but could change to using Apache2::Request if
> needed.
>
> Cheers, Jon.
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for
> Conference
> attendees to learn about information security's most important issues
> through
> interactions with peers, luminaries and emerging and established
> companies.
> http://p.sf.net/sfu/rsaconf-dev2dev_______________________________________________
> Mason-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mason-users
>
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Mason-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mason-users
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Mason-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mason-users
