Re: mod_include and POST (fwd)

[Greg Stein <gs...@lyra.org>]

[ moving to dev@httpd.apache.org... ]

On Sat, Aug 25, 2001 at 09:53:51PM -0400, Cliff Woolley wrote:
> On Sat, 25 Aug 2001, Brian Pane wrote:
> > However, it also seems to break something else:
> >
> > With this new code, any POST response that goes through the mod_include
> > filter will result in a 405.  That's bad news for anybody who needs to
> > stream the output of a POST-based CGI/JSP/etc app through mod_include
> > for SSI processing.
> >
> > Would it make sense to replace:
> >     if (r->method_number != M_GET) {
> > with:
> >     if ((r->method_number != M_GET) && (r->method_number != M_POST)) {
> > in order to support SSI parsing of dynamically generated reponses to
> > POSTs?
> 
> It's fine by me... it was not supported by 1.3, but then again the ability
> to server-parse dynamically generated content is a new feature.  I'll make
> the change.  It does work, BTW-- I tried it yesterday.  It makes the stuff
> to fight with OPTIONS requests a bit redundant, but it's probably good to
> keep it in anyway in case somebody tries to stick mod_include on top of a
> handler that supports more than just GET and POST.

Detecting the method in there is almost always the wrong thing to do. I
could easily imagine a case where a server responds to a XXX method with an
error document that is server-parsed. (say, XXX is MOVE or COPY or
MY-CUSTOM-METHOD)

Hmm... guess I should go read the original motivation for this, but it seems
that whatever the problem was, it should be solved differently.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/