httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [PATCH] ap_add_filter
Date Thu, 17 Aug 2000 14:27:28 GMT

In a message dated 00-08-17 13:42:55 EDT, Greg Marr writes...

>  At 12:53 PM 08/17/2000, wrote:
>  >I know this is just a 'first pass' and all but I also don't see any 
>  >way to 'back out' once the process has started.  Example: What if a 
>  >CONNECTION filter does try to insert
>  >some other type of filer immediately after itself and, since this 
>  >might not be allowed, the add filter function fails and returns an 
>  >error... where is the code to restore the headers and simply 
>  >continue without the filtering added?
>  The filter can simply attempt to add the filter, and then if it it 
>  succeeds, modify the headers and keep going?  Why would there be any 
>  need to restore the headers?

Because, given the current design approach, to actually ADD 
some filters the headers ( and/or the request rec itself )  might 
already need to be 'set up' with certain values or the install won't work.

I think it's obvious to everyone that there is still one glaring
black hole in the design and that is, in fact, the proper alteration
and management of the HTTP header content itself during the
filtering phase(s). It's still just not clear how all that is supposed
to work and who is either responsible for or allowed to do what
and when with regards to the HTTP header content.

Even the approach I suggested won't work for certain types 
of filters and there might need to be some 'fake' changes made
to the headers just to even check and see if the install will
succeed and someone ( or something ) is going to have to put
the headers back the way they were if the install fails and 
there have already been filter-specific changes made to the

Indeed... what if the filter install actually succeeds but then
the filter goes belly-up when the first data bucket arrives.
Who undoes the headers and what is the final output? A
5xx Internal Server Error or does the whole output chain
just go away and the connection times out eventually?

Also... it just seems that the patches being submitted are simply
assuming that everything succeeds all the time and it isn't even
doing what you suggest ( which would also work fine ).

>  >Perhaps you could use the 'Santa Claus' approach used by many other 
>  >API's. It's the 'Checking it once checking it twice' approach.
>  >
>  >Any time a filter is going to be added it needs to simply ATTEMPT to 
>  >do it ( checking it once ) and then check the return code.  The 
>  >first check actually does nothing
>  >but make sure that all WILL go well and the filter addition will, in 
>  >fact, succeed... but nothing has really happened to alter the 
>  >processing chain (yet). If the return code is OK only then are the 
>  >output headers altered and the REAL filter insertion call takes 
>  >place. ( second part of Santa Claus approach ).
>  The second step isn't necessary, and the first can just go ahead and 
>  do it.

See above. Given the current design and the fact that some filters
I can imagine will actually NEED the header changes made before
the install will succeed I think the 'check first' approach makes the
most sense. 

We are, of course, now talking about 'dependencies' which is a
can of worms that has yet to open. For now... the simple 'check
first' will tell you about basic 'that's a no-no' install errors. The
relationship between the header values and the actual full install
of a filter is a whole 'nother story at this point.
>  >If the return code on the first call FAILS then no harm done. The 
>  >filter has not really been installed yet and the headers are left 
>  >alone. Nothing has to be 'undone' because the filter didn't even get 
>  >installed.
>  Even without the extra check, if the insertion fails, then nothing 
>  has to be undone because the filter didn't get installed.

It depends. Even if the filter didn't install... what restrictions and
rules are there about it 'touching' the headers during the install
and then 'undoing' those changes if the install craps out for
some other reason?
>  >if (r->chunked) {
>  >
>  >/* Check and see if the filter we want to add ( and whatever */
>  >/* filters that filter wants to install ) is all going to succeed */
>  >/* before we alter the processing chain... */
>  >
>  >if ( ap_add_filter("CHUNK", -1, r, NULL ) {
>  >     /* Yes... the filter we want WILL install OK so go ahead */
>  >     /* and touch the headers and do the REAL install... */
>  >     apr_table_mergen(r->headers_out, "Transfer-Encoding", "chunked");
>  >     apr_table_unset(r->headers_out, "Content-Length");
>  >     ap_add_filter("CHUNK", NULL, r, NULL);
>  >    }
>  >else {
>  >     /* The filter that we wanted to add has something wrong with */
>  >     /* it and the ap_add_filter() call returned an error. Since */
>  >     /* we have only issued a 'check once' call so far then no */
>  >     /* harm done. The output headers haven't been touched yet. */
>  >     /* Just continue normally without that filter... */
>  >    }
>  >}
>  Or even cleaner:
>  if (r->chunked) {
>       /* Wait until the filter insertion succeeds before we alter the */
>       /* processing chain... */
>       if (ap_add_filter ("CHUNK", NULL, r, NULL ) {
>           apr_table_mergen(r->headers_out, "Transfer-Encoding", 
>  "chunked");
>           apr_table_unset(r->headers_out, "Content-Length");
>           }
>       else {
>           /* The filter that we wanted to add has something wrong with 
>  */
>           /* it and the ap_add_filter() call returned an error. */
>           /* Just continue normally without that filter... */
>       }
>  }

That works just as well as long as the filter is not one of those
that is dependent on 'seeing' certain header fields before the
install will actually succeed.

I guess it all comes down to this...

At what point during the installation of a filter does the filter
writer himself get to make sure that all the resources that
are needed are available and that the Inbound user-agent
is compatible with the filtering itself? Does the absence
of any dependency constitute a FAILURE at the point we
are focusing on or does that kind of stuff have to wait until
the data starts arriving and only then can the 'guts' of the
filter decide to REMOVE itself ( and undo the headers ) if
something goes wrong.

In other words... where is the real 'Are we going to be able
to do this?' code for filter installation(s) and what is the
actual 'tear it all down and undo everything' back-out procedure?

Kevin Kiley
CTO, Remote Communications, Inc. - Online Internet Content Compression Server.

View raw message