httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: mod_include and POST (fwd)
Date Sun, 26 Aug 2001 09:22:56 GMT
[ moving to ]

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

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


Greg Stein,

View raw message