httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: Filter I/O take 3.
Date Sat, 17 Jun 2000 02:47:21 GMT

> > Issues not resolved:
> >      Negative pushback from the network (there is a comment in the code
> > for how to implement this)
> 
> I could not find this comment, or see how it could be done.

Look for MAX_STRING_LENGTH.  This is to throttle the server from sending
too much data.

> This solution has covered the "return an FD so that sendfile() can be used",
> but doesn't cover these items very well:  (from my "recap" email)
> 
> *) complexity due to the ioblock/ioqueue stuff

I still don't agree with the complexity issue.  Especially not with all of
the helper functions that can/will/have been created.  

> *) I do not understand how sub requests are handled in this scheme
>    (essentially, how are the two sets of hooks joined together)

Since a sub request and main request share the buffer, and the filters,
this should just work.  I don't see the issue (see my last note about my
day and why I shouldn't be reading e-mail if this is something obvious I
am missing).

> *) if I fetch 100Mb from a database for insertion into the content stream,
>    how does that work in this scheme? (flow control, working set)

The same way it works in your scheme.  You add a 100MB iovec, and it gets
sent to the next filter.  In my scheme, that 100MB will be chuncked and
sent in smaller chunks, my it gets there all the same.

> >...
> > @@ -1394,7 +1474,8 @@
> >  API_EXPORT_NONSTD(int) ap_send_header_field(request_rec *r,
> >      const char *fieldname, const char *fieldval)
> >  {
> > -    return (0 < ap_rvputs(r, fieldname, ": ", fieldval, CRLF, NULL));
> > +    return (0 < ap_bvputs(r->connection->client, fieldname, ": ", fieldval,

> > +                          CRLF, NULL));
> 
> These are not equivalent. Specifically, ap_rvputs() deals with aborted
> connections, and with logging an error when a connection aborts.
> 
> I think we need a few "internal" functions that http_protocol can use which
> are just slim covers over ap_bvputs() and friends. They would be equivalent
> to the *current* ap_rvputs() and friends (the new ap_rvputs calls into the
> filtering/layering).

That's fine.  This is a first pass, and I didn't really investigate the
headers stuff too much.

> > ap_ioqueue_t *gargle_filter(request_rec *r, ap_ioqueue_t *strs)
> > {
> >     static int dummy = 0;
> >     ap_ioblock_t *dptr = strs->head;
> > 
> >     while (dptr != NULL) {
> >         if (dptr->len > 10) {
> >             ap_ioblock_t *temp;
> > 
> >             ap_split_ioblock(dptr, 9);
> >             dptr = dptr->next;
> >             ap_split_ioblock(dptr, 1);
> >             ap_split_ioblock(dptr->next, 1);
> >            
> >             temp = dptr->next;
> >             temp->prev = dptr->prev;
> >             dptr->next = temp->next;
> >             temp->next = dptr;
> >             dptr->prev->next = temp;
> >             dptr->prev = temp;
> >         }
> > #if 0
> >         if (dummy == 0) {
> >             ap_ioqueue_t *d2 = ap_start_ioqueue(dptr->next);
> >             dummy = 1;
> >             dptr->next = NULL;
> >             return d2;
> >         }
> > #endif
> >         dptr = dptr->next;
> >     }
> >     return NULL;
> > }
> 
> Um... what does this do? I can't tell. It looks like it is breaking up input
> chunks into smaller chunks, then doing something.
> 
> I'll write an equivalent mod_gargle and/or some other examples, but at this
> point, I can't duplicate the above code until I know what it does :-)

It just flips the every 10 and 11 characters.  I did some messy pointer
stuff because I really didn't care about this being clean.  I also have
some code in there to test some other features that aren't fully
implemented yet.  That makes some of this code ugly, because I am setting
up contrived situations.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message