On Sun, 29 Jul 2007 13:37:20 +0200
Ruediger Pluem <[EMAIL PROTECTED]> wrote:
> [as usual, catching my bugs - thanks]
> > + if (!strcasecmp(token, "gzip")) {
> > + char *new_encoding = apr_pstrdup(r->pool,
> > encoding);
> > + char *ptr = ap_strstr(new_encoding, token);
> > + size_t sz = 5*sizeof(char);
> > + if (ptr == new_encoding) {
> > + /* remove "gzip:" at start */
> > + memmove(ptr, ptr+sz, sz);
>
> Maybe I am missing the point, but if gzip is at the start why moving
> memory and not simply increasing new_encoding by 5?
Good point.
>
> > + }
> > + else {
> > + /* remove ":gzip" as found */
> > + memmove(ptr-sizeof(char),
> > ), sz);
>
> Is this correct? memmove maybe bcopy on platforms where no memmove is
> available and as I understand the man pages of memmove and bcopy it
> would only copy sz bytes from behind gzip to the old position of the
> gzip string. What if you have
Even better point. That last sz should be strlen(ptr+4*sizeof(char))+1,
to include the terminator in what's moved.
> And BTW, as the order of the encodings in Content-Encoding must be
> the order in which they have been applied, don't we need to ensure
> that gzip needs to be at the *end* of the content encoding string, as
> we have to decode things in the reverse order? Otherwise we would try
> to decode a gzip encoding when there is still another encoding on top
> of gzip.
OK, that's inherited from the existing version, both input and output
filters. I guess the moral is, we've never done more than pay
lip-service to multiple content-encodings.
I'm about to go out now, so an update will have to wait:-)
Thanks,
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
