You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Hans <ha...@locehilios.com> on 2003/09/08 08:12:08 UTC
Sending a different protocol header
I've done a fair amount of searching and still can not find an answer to
this.
I'm writing a mod_perl2 handler and would like to output my own headers.
Specifically I'd like to output headers like this:
-----------------------------
ICY 200 OK
icy-notice1: <some info>
icy-name: <some info>
icy-url: <some info>
Content-Length: <length>
<SOME CONTENT>
-----------------------------
When trying to output these headers it doesn't work and just becomes part
of the content. If I remove the "ICY 200 OK" line, the rest of the
headers work just fine. I'd like to override the "HTTP/1.1" headers. How
can this be done?
I also tried changing the ICY line above to "Status: ICY 200 OK", and the
server ended up outputing, "HTTP/1.1 ICY 200 OK"
I've read the documentation and posts about PerlOptions +ParsedHeaders,
etc. but nothing has pointed me to a way to completely control the
headers that are being sent out.
Please help!
-HANS
Re:[OT] Sending a different protocol header
Posted by Issac Goldstand <ma...@beamartyr.net>.
> btw, can you please explain what ICY is for me? the $r->assbackwards(1)
> thing was specifically implemented in mod_perl 1.0 to support ICY, and I
> used it in examples I give of this, but I always have to say that I have
no
> idea what ICY is.
>
IceCast. The LINUX version of WinAmp's streaming MP3 server.
Issac
Re: Sending a different protocol header
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>
> Perrin Harkins wrote:
>
>> On Mon, 2003-09-08 at 13:12, Geoffrey Young wrote:
>>
>>> actually, the assbackwards slot of the request record is there to
>>> indicate
>>> that the incoming request used HTTP/0.9, which defines only GET and
>>> where no
>>> headers are expected in the response.
>>
>>
>>
>> Clearly this works, but wouldn't it be better to implement a protocol
>> handler for IceCast instead? Or is that just overkill for this?
[...]
> but yes, hans, for the record Apache 2.0 and mod_perl 2.0 both support
> the idea of protocol handlers, if you're interested. see
>
> http://perl.apache.org/docs/2.0/user/handlers/protocols.html
And an example of how to extend HTTP protocol, without inventing a new one
(this example extends HTTP to support "invented" by me EMAIL protocol):
http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlHeaderParserHandler
__________________________________________________________________
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: Sending a different protocol header
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Perrin Harkins wrote:
> On Mon, 2003-09-08 at 13:12, Geoffrey Young wrote:
>
>>actually, the assbackwards slot of the request record is there to indicate
>>that the incoming request used HTTP/0.9, which defines only GET and where no
>>headers are expected in the response.
>
>
> Clearly this works, but wouldn't it be better to implement a protocol
> handler for IceCast instead? Or is that just overkill for this?
I dunno. that IceCast is a protocol seems to make it a perfect candidate
for a protocol handler. however, since I have yet to play with that aspect
of apache or mod_perl, I don't know the overhead involved, especially if an
ICY request is the same as an HTTP request, and supressing headers is the
only difference between HTTP and ICY responses.
but yes, hans, for the record Apache 2.0 and mod_perl 2.0 both support the
idea of protocol handlers, if you're interested. see
http://perl.apache.org/docs/2.0/user/handlers/protocols.html
--Geoff
Re: Sending a different protocol header
Posted by Perrin Harkins <pe...@elem.com>.
On Mon, 2003-09-08 at 13:12, Geoffrey Young wrote:
> actually, the assbackwards slot of the request record is there to indicate
> that the incoming request used HTTP/0.9, which defines only GET and where no
> headers are expected in the response.
Clearly this works, but wouldn't it be better to implement a protocol
handler for IceCast instead? Or is that just overkill for this?
- Perrin
Re: Sending a different protocol header
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> "assbackwards" works. Thanks!
>
> When I first read your response about a method called "assbackwards" I
> thought it was sarcasm :)
understandable :)
actually, the assbackwards slot of the request record is there to indicate
that the incoming request used HTTP/0.9, which defines only GET and where no
headers are expected in the response. so, for HTTP/0.9 requests
r->assbackwards is 1, otherwise it is 0.
apache internally hacks r->assbackwards on various occasions where headers
should be supressed in the response, such as with a subrequest.
mod_perl also hacks the assbackwards flag to suit its needs. in mod_perl
1.0 $r->assbackwards did not exist (except in various XS extensions created
solely for educational purposes :) but one of the cool things about mod_perl
2.0 is that the entire API is opened up (finally :)
>
> ICY is for IceCast, a protocol for sending meta information about music
> streams.
cool, thanks.
--Geoff
Re: Sending a different protocol header
Posted by ha...@locehilios.com.
On Mon, Sep 08, 2003 at 08:51:13AM -0400, Geoffrey Young wrote:
> try setting $r->assbackwards(1) before returning your response. this
> should supress the apache headers and allow only your own to get through,
> provided you print them instead of putting them in the headers_out table.
>
> btw, can you please explain what ICY is for me? the $r->assbackwards(1)
> thing was specifically implemented in mod_perl 1.0 to support ICY, and I
> used it in examples I give of this, but I always have to say that I have no
> idea what ICY is.
>
> thanks
>
> --Geoff
>
"assbackwards" works. Thanks!
When I first read your response about a method called "assbackwards" I thought it was sarcasm :)
ICY is for IceCast, a protocol for sending meta information about music streams.
Thanks again.
-HANS
Re: Sending a different protocol header
Posted by Chris Shiflett <sh...@php.net>.
--- Geoffrey Young <ge...@modperlcookbook.org> wrote:
> btw, can you please explain what ICY is for me?
I believe ICY is a protocol used for streaming media, so these headers are
probably an extension of HTTP that can be used instead of the pure ICY
protocol. That's a guess, anyway. :-)
Chris
=====
Become a better Web developer with the HTTP Developer's Handbook
http://httphandbook.org/
Re: Sending a different protocol header
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Hans wrote:
> I've done a fair amount of searching and still can not find an answer to
> this.
>
> I'm writing a mod_perl2 handler and would like to output my own headers.
> Specifically I'd like to output headers like this:
> -----------------------------
> ICY 200 OK
> icy-notice1: <some info>
> icy-name: <some info>
> icy-url: <some info>
> Content-Length: <length>
>
> <SOME CONTENT>
> -----------------------------
> When trying to output these headers it doesn't work and just becomes part
> of the content. If I remove the "ICY 200 OK" line, the rest of the
> headers work just fine. I'd like to override the "HTTP/1.1" headers. How
> can this be done?
try setting $r->assbackwards(1) before returning your response. this should
supress the apache headers and allow only your own to get through, provided
you print them instead of putting them in the headers_out table.
btw, can you please explain what ICY is for me? the $r->assbackwards(1)
thing was specifically implemented in mod_perl 1.0 to support ICY, and I
used it in examples I give of this, but I always have to say that I have no
idea what ICY is.
thanks
--Geoff