You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Marc M. Adkins" <Pe...@Doorways.org> on 2007/12/16 03:56:20 UTC
Can output filter return "page not found"?
I'm trying to cause a 404 error from an output filter and it isn't doing
what I expect. Is this even possible?
mma
Re: Can output filter return "page not found"?
Posted by "Marc M. Adkins" <Pe...@Doorways.org>.
Thought I had it. Used $filter->r->status() to set the status code on
the request from within the output filter. That would have made sense
and resulted in a big "d'oh!" Sadly it doesn't seem to change the
result either.
Time to do something else for a while. Thanks in advance for any hints.
mma
Marc M. Adkins wrote:
> Hmmm...it's a bucket brigade FilterRequestHandler output filter. It
> seems to not care what return code I use, whatever is in the bucket
> brigade goes out. Can I not return Apache2::Const::NOT_FOUND from
> handler()? That seems odd.
>
> Marc M. Adkins wrote:
>> I'm trying to cause a 404 error from an output filter and it isn't
>> doing what I expect. Is this even possible?
>>
>> mma
>>
>
>
Re: Can output filter return "page not found"?
Posted by Colin Wetherbee <cw...@denterprises.org>.
Marc M. Adkins wrote:
> Can I not return Apache2::Const::NOT_FOUND from handler()?
I've never used filters for this, but you can certainly return NOT_FOUND
from a handler.
Colin
Re: Can output filter return "page not found"?
Posted by "Marc M. Adkins" <Pe...@Doorways.org>.
Implemented Fixup handler and it works fine. Thanks all.
Marc M. Adkins wrote:
> I'm actually thinking the same thing. I've been looking for a
> configuration setting that will just notice that the file isn't there
> and 404, but I think the fact that there IS a response handler is
> causing Apache to skip the check for the existence of the file. Failing
> a simpler configuration fix I think there's no choice but to fail early
> as you both suggest.
>
> It does seem like a different kind of wasted effort. Now I'm going to
> check for the template in an additional handler for each and every
> request. Since the majority of requests should be correct this is
> wasted cycles for most requests.
>
> Failing out of the output handler wastes the data generation phase, but
> that's lightweight for most of this particular site and the percentage
> of 404 pages will likely be also.
>
> Is:
>
> [found-ratio] * [pre-check-time]
>
> more or less than:
>
> [not-found-ratio] * [data-generation-time]
>
> ?
>
> Fortunately this is just a hobby site so I don't have to care too much.
> And if I care, I can always instrument the code to find out the actual
> values of the three variables.
>
> I do think that there should be a clear way to return a 404 (or any
> other code) from the output filter if desired.
>
> mma
>
> Adam Prime wrote:
>> deepfryed@gmail.com wrote:
>>> Sounds like something I would *not* do. If you are going to return a
>>> 404, why not do it as soon as possible.
>>> Generating data only to return a 404 sounds like useless extra work
>>> unless you are caching the same data for future requests.
>>>
>>
>> I agree, if you don't want to much up your data generation code, write
>> an Access or Fixup Handler (or any other pre-response phase handler of
>> your choice) checks for the existence of the template at that stage.
>> If it's not there, 404.
>>
>> Adam
>>
>>
>>
>
>
Re: Can output filter return "page not found"?
Posted by "Marc M. Adkins" <Pe...@Doorways.org>.
I'm actually thinking the same thing. I've been looking for a
configuration setting that will just notice that the file isn't there
and 404, but I think the fact that there IS a response handler is
causing Apache to skip the check for the existence of the file. Failing
a simpler configuration fix I think there's no choice but to fail early
as you both suggest.
It does seem like a different kind of wasted effort. Now I'm going to
check for the template in an additional handler for each and every
request. Since the majority of requests should be correct this is
wasted cycles for most requests.
Failing out of the output handler wastes the data generation phase, but
that's lightweight for most of this particular site and the percentage
of 404 pages will likely be also.
Is:
[found-ratio] * [pre-check-time]
more or less than:
[not-found-ratio] * [data-generation-time]
?
Fortunately this is just a hobby site so I don't have to care too much.
And if I care, I can always instrument the code to find out the actual
values of the three variables.
I do think that there should be a clear way to return a 404 (or any
other code) from the output filter if desired.
mma
Adam Prime wrote:
> deepfryed@gmail.com wrote:
>> Sounds like something I would *not* do. If you are going to return a
>> 404, why not do it as soon as possible.
>> Generating data only to return a 404 sounds like useless extra work
>> unless you are caching the same data for future requests.
>>
>
> I agree, if you don't want to much up your data generation code, write
> an Access or Fixup Handler (or any other pre-response phase handler of
> your choice) checks for the existence of the template at that stage. If
> it's not there, 404.
>
> Adam
>
>
>
Re: Can output filter return "page not found"?
Posted by Adam Prime <ad...@utoronto.ca>.
deepfryed@gmail.com wrote:
> Sounds like something I would *not* do. If you are going to return a
> 404, why not do it as soon as possible.
> Generating data only to return a 404 sounds like useless extra work
> unless you are caching the same data for future requests.
>
I agree, if you don't want to much up your data generation code, write
an Access or Fixup Handler (or any other pre-response phase handler of
your choice) checks for the existence of the template at that stage. If
it's not there, 404.
Adam
Re: Can output filter return "page not found"?
Posted by de...@gmail.com.
Sounds like something I would *not* do. If you are going to return a
404, why not do it as soon as possible.
Generating data only to return a 404 sounds like useless extra work
unless you are caching the same data for future requests.
On 12/17/07, Marc M. Adkins <Pe...@doorways.org> wrote:
> Thanks, good hint. I was thinking that myself overnight.
>
> Here's the basic scenario:
>
> I use the main request handler to generate XML. I have a framework that
> allows me to glue together various sub-handlers (from my framework, not
> Apache handlers) to add disparate data elements into the XML depending
> on the context of the page.
>
> Then I use an output filter to process the XML using XSLT. This
> completely separates data from presentation. Works really well except
> for my current issue. Seems like a reasonable use of the Apache 2.x
> handler structure.
>
> So I don't actually know whether the template exists until the output
> filter. I don't want to pollute my data generation phase with checking
> ahead for the template. I'm also not sure why Apache isn't detecting
> that the template doesn't exist ... it should look like any other
> servable resource.
>
> So before I start messing with headers I think I'll look at the way my
> configuration file is set up. Perhaps I'm doing something stupid there.
> I'm using <Location> instead of <FilesMatch> (or whatever) to
> configure the output filter ... maybe it's something like that.
>
> Thanks again!
>
> Adam Prime wrote:
> > If you're using the bucket brigade API you'd have to intercept the
> > headers and modify them there. You might have an easier time doing
> > something like this using the stream API, but i don't really know, just
> > taking a shot in the dark. I'd think that it's certainly possible
> > though, somehow.
> >
> > That said you might be better served catching whatever situation is
> > causing you to want to do this earlier in the request cycle and keeping
> > the response phase from doing whatever it wants to do in the first place
> > and just causing the 404 to happen then.
> >
> > Adam
> >
> > Marc M. Adkins wrote:
> >> Hmmm...it's a bucket brigade FilterRequestHandler output filter. It
> >> seems to not care what return code I use, whatever is in the bucket
> >> brigade goes out. Can I not return Apache2::Const::NOT_FOUND from
> >> handler()? That seems odd.
> >>
> >> Marc M. Adkins wrote:
> >>> I'm trying to cause a 404 error from an output filter and it isn't
> >>> doing what I expect. Is this even possible?
> >>>
> >>> mma
> >>>
> >>
> >
> >
>
>
Re: Can output filter return "page not found"?
Posted by "Marc M. Adkins" <Pe...@Doorways.org>.
Thanks, good hint. I was thinking that myself overnight.
Here's the basic scenario:
I use the main request handler to generate XML. I have a framework that
allows me to glue together various sub-handlers (from my framework, not
Apache handlers) to add disparate data elements into the XML depending
on the context of the page.
Then I use an output filter to process the XML using XSLT. This
completely separates data from presentation. Works really well except
for my current issue. Seems like a reasonable use of the Apache 2.x
handler structure.
So I don't actually know whether the template exists until the output
filter. I don't want to pollute my data generation phase with checking
ahead for the template. I'm also not sure why Apache isn't detecting
that the template doesn't exist ... it should look like any other
servable resource.
So before I start messing with headers I think I'll look at the way my
configuration file is set up. Perhaps I'm doing something stupid there.
I'm using <Location> instead of <FilesMatch> (or whatever) to
configure the output filter ... maybe it's something like that.
Thanks again!
Adam Prime wrote:
> If you're using the bucket brigade API you'd have to intercept the
> headers and modify them there. You might have an easier time doing
> something like this using the stream API, but i don't really know, just
> taking a shot in the dark. I'd think that it's certainly possible
> though, somehow.
>
> That said you might be better served catching whatever situation is
> causing you to want to do this earlier in the request cycle and keeping
> the response phase from doing whatever it wants to do in the first place
> and just causing the 404 to happen then.
>
> Adam
>
> Marc M. Adkins wrote:
>> Hmmm...it's a bucket brigade FilterRequestHandler output filter. It
>> seems to not care what return code I use, whatever is in the bucket
>> brigade goes out. Can I not return Apache2::Const::NOT_FOUND from
>> handler()? That seems odd.
>>
>> Marc M. Adkins wrote:
>>> I'm trying to cause a 404 error from an output filter and it isn't
>>> doing what I expect. Is this even possible?
>>>
>>> mma
>>>
>>
>
>
Re: Can output filter return "page not found"?
Posted by Adam Prime <ad...@utoronto.ca>.
If you're using the bucket brigade API you'd have to intercept the
headers and modify them there. You might have an easier time doing
something like this using the stream API, but i don't really know, just
taking a shot in the dark. I'd think that it's certainly possible
though, somehow.
That said you might be better served catching whatever situation is
causing you to want to do this earlier in the request cycle and keeping
the response phase from doing whatever it wants to do in the first place
and just causing the 404 to happen then.
Adam
Marc M. Adkins wrote:
> Hmmm...it's a bucket brigade FilterRequestHandler output filter. It
> seems to not care what return code I use, whatever is in the bucket
> brigade goes out. Can I not return Apache2::Const::NOT_FOUND from
> handler()? That seems odd.
>
> Marc M. Adkins wrote:
>> I'm trying to cause a 404 error from an output filter and it isn't
>> doing what I expect. Is this even possible?
>>
>> mma
>>
>
Re: Can output filter return "page not found"?
Posted by "Marc M. Adkins" <Pe...@Doorways.org>.
Hmmm...it's a bucket brigade FilterRequestHandler output filter. It
seems to not care what return code I use, whatever is in the bucket
brigade goes out. Can I not return Apache2::Const::NOT_FOUND from
handler()? That seems odd.
Marc M. Adkins wrote:
> I'm trying to cause a 404 error from an output filter and it isn't doing
> what I expect. Is this even possible?
>
> mma
>