Re: Sending a different protocol header
--- Geoffrey Young [EMAIL PROTECTED] 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
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
Re: Sending a different protocol header
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
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
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
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 BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
