Ryan Bloom wrote:
> Woah. Those are build differences, not C-code differences. Those can
> all be handled with some simple m4 configure scripts. Why are we wrapping
> C-code? What differences are we abstracting with the C code?
The C differences are involved with standardising between some
d
sterling wrote:
> > Well, it did have a portability function in that it smoothed out
> > differences between various LDAP libraries (openldap/netscape/iplanet)
> > rather than various platforms (unix/nt/etc).
>
> what differences are smoothed out? maybe i'm looking in the wrong place,
> but i d
Ryan Bloom wrote:
> No. That is where we started from. Graham sent a large patch that did all
> of this, but a lot of it didn't really belong in APR or APR-util, because
> it had nothing to do with portability.
Well, it did have a portability function in that it smoothed out
differences betwee
"William A. Rowe, Jr." wrote:
> No, please move it first. This creates four communities (proxy, pop, mbox,
> and ldap) that all share a desire to get this resolved. A fifth is likely
> on it's way - there are users in some parts of the world that cannot *legally*
> download or checkout httpd wi
Ryan Bloom wrote:
> I realize that this is a small piece, but the message posted by Will
> also doesn't say anything about mod_auth_ldap.c.
mod_auth_ldap is that part of the LDAP patch that does the actual useful
work (mod_ldap does nothing useful on it's own). I put it in modules/aaa
because I
Sterling Hughes wrote:
> I'm developing a module (httpd2.0) and I've come across a situation
> where it would be great if I could "cache" an operation, by saving a
> variable in memory, and keep it there throughout requests, ie:
Take a look inside the code inside httpd-2.
Hi all,
Someone mentioned a patch they had that added a "require owner"
directive to authenticate a user. Was this patch posted anywhere?
Regards,
Graham
--
-
[EMAIL PROTECTED]"There's a moon
over B
Ryan Bloom wrote:
> If you use a pre-processor, then you can make a sane decision. If the LDAP
> server isn't responding, don't tell Apache to restart. If you get half-way through
> updating the config file on disk, don't try to restart Apache. If you mix the two,
> you open yourself up to more
Ryan Bloom wrote:
> This has been discussed before, and was the original goal for the
> configuration tree approach. The decision in the past has always been
> that Apache config files are stored text files. If you want to store them
> somewhere else, then create a pre-processor to grab the con
Aaron Bannert wrote:
> The attack is the same, but the result is different. Named virtual hosts
> only really affect how the client contacts the server, and everything
> else happens in HTTP (in the Host: header). You can not prevent someone
> from altering their own DNS entries maliciously. OTOH
Ryan Bloom wrote:
> This has been discussed before, and was the original goal for the
> configuration tree approach.
Ok.
> The decision in the past has always been
> that Apache config files are stored text files. If you want to store them
> somewhere else, then create a pre-processor to grab
Aaron Bannert wrote:
> One of the biggest dangers in this kind of a thing (and it is rather similiar
> to depending on a remote DTD in XML) is that you are now implicitly trusting
> DNS for authenticity. A poisoned DNS entry could be catastrophic.
We face that problem today with the virtualhost
Hi all,
Part two in the grand LDAP plan is to support the storing of
configuration data in an LDAP directory, somewhat along the lines of
what has been achieved with qmail+ldap+control. This allows multiple
machines (probably in a redundant configuration) to derive their config
from a common data
Hi,
This is the first module to use the LDAP functionality: mod_auth_ldap.
The module allows users to be authenticated against an LDAP database,
and then authorised against various "require" directives, including LDAP
group membership.
The file lives in the following directory:
modules/aaa/mod_
Tarun Upadhyay wrote:
> however, the only stumbling block on that road is that typically a SOAP call
> will be made from inside a program (and not from a human-oriented interface)
> so I don't know if I all authentication modules will make sense. But I guess
> we can live with that.
Well - Apach
Carlos Costa Portela wrote:
> > The proxy cache can run on a different machine, or the same machine, or
> > even be a separate virtual host on the webserver (if the image
> > manipulator and the cache are both Apache).
>
> When you say "both Apache" you want to say "both Apache modules",
Carlos Costa Portela wrote:
> 1st. Build by own web-image server. Just receive requests, examine it,
> processing and return.
>
> 2nd. Use apache for doing it.
The easiest way to do this is to use a dedicated caching layer to cache
your images. An Apache based reverse proxy can be used to do th
"Peter J. Cranstone" wrote:
> To garner more acceptance of Apache 2.0 it would probably be smart to
> run some sample test configs of 1.3.x vs. 2.x and publish the actual
> performance metrics.
>
> It's now a marketing job to convince people that the new features are
> worth moving to. The real
Tarun Upadhyay wrote:
> Our basic design allows the use of another module (say mod_auth or
> something else) to authenticate users but through an "access file", we
> authorize users to connect to particular web-service or its methods.
>
> We want the user to be able to authorize users at either
Yulya Blyakh wrote:
> telnet www.ukrbiz.net 80
> ..
> GET / HTTP/1.0
>
> HTTP/1.1 400 Bad Request
> In response, I get 400 error, and it seems that APACHE doesn't know how to
> process my inquiry.
Apache is giving you the correct response to this request.
> GET / HTTP/1.0
> Host: www.ukrb
Hi all,
Here is the other half of the LDAP authentication capability for Apache
v2.0 - mod_auth_ldap. It is designed to work with the LDAP extensions to
apr-util posted in the APR developers list.
Enable the module with --with-ldap --enable-auth-ldap.
The module works for me, but still needs a
Hi all,
The CVS problems seem to be related to the /tmp directory on icarus
being writable only by root:
drwxr-xr-x 2 root wheel 512 Jul 31 15:26 tmp
Can someone fix this?
Regards,
Graham
--
-
[EMAIL PROTECTED]"There's a moon
Hi all,
Just had some problems trying to update the httpd-2.0 tree. When I use
cvs.apache.org it complains that the host key has changed. If I use
icarus.apache.org, I get an error saying "can't create temporary
directory /tmp/" and then "permission denied".
I understand that things were moved a
Hi all,
I am having a very odd problem with Apache v1.3.19. I have a single
virtualhost configured for a specific website with a specific ServerName
specified. I have a second general virtualhost configured as a
"catchall" that points to the default Apache page.
For some odd reason that I cannot
Hi all,
A project that I have been meaning to get started for a while is to add
LDAP support to Apache v2.0. The stuff I have in mind are:
- Authentication against an LDAP server (a number of modules already
exist to do this for v1.3)
- Configuration information stored in an LDAP server (for mul
[EMAIL PROTECTED] wrote:
> > Return to whom? Clearly if you remove the TLS filter, it won't be the
> > user!
>
> Yep, right now TLS is broken. I don't have a great idea for how to fix it
> though. :-(
Have reset_filters() not remove the TLS filter if it is there?
Regards,
Graham
--
sterling wrote:
> reset_filters always removed all filters (including TLS). This is a
> problem in general - I think the only reason the filters are all removed
> on error is to prevent infinite recursion (in the case where the error
> came from one of the filters). Optimally, if I add a filter
[EMAIL PROTECTED] wrote:
> Fix the reset_filters function. If we set r->output_filters to NULL,
> then we also have to reset the connection's filters.
> Submitted by: John Sterling <[EMAIL PROTECTED]>
Will this not break if there is a TLS filter hanging around? This will
make the TLS filt
Thomas Eibner wrote:
> I would have liked for a better way to turn off keepalive for the last
> request of the child, than just terminating it, but I couldn't find a way
> to turn off keepalive before the headers were sent and ap_process_request
> was called.
If I understand you right then this
[EMAIL PROTECTED] wrote:
> > > void reset_filters(r)
> > > {
> > > ap_filter_t *f = r->output_filters;
> > > int has_core = 0, has_content = 0, has_http_header = 0;
> > > while (f) {
> > > ap_filter_t *f2 = f->next;
> > > ap_remove_filter(f);
> > > f = f2;
> >
[EMAIL PROTECTED] wrote:
> This could be made MUCH simpler by just changing reset_filters to:
>
> void reset_filters(r)
> {
> ap_filter_t *f = r->output_filters;
> int has_core = 0, has_content = 0, has_http_header = 0;
> while (f) {
> ap_filter_t *f2 = f->next;
> ap_
[EMAIL PROTECTED] wrote:
> Add the 'echo' option to mod_headers Header directive. Use the new option
> like this:
>
> Header echo regex
>
> If a header received on a request matches regex, it is copied to the response
> headers.
Would it not make more sense to add "echo" to RequestHe
sterling wrote:
> Since there needs to be some design work to figure out the best place to
> insert the header filters, i suggest we backout the change that inserts
> them in the 'insert filters' phase -
The HTTP_HEADER filter needs to be inserted last - any filter that ends
up being run after t
sterling wrote:
> Since there needs to be some design work to figure out the best place to
> insert the header filters, i suggest we backout the change that inserts
> them in the 'insert filters' phase -
>
> here is a patch for it, in case you don't want to just undo the original
> commit:
This
"William A. Rowe, Jr." wrote:
> John Sterling noted this as well, and has submitted a patch to correct it.
> Expect some action early this week.
>
> If you are right, it would be interesting to discover 'what changed' in
> light of the fact that it worked so recently. No doubt another optmizati
sterling wrote:
> That would work IFF reset_filters guarentees that there is only one
> instance of each of those filters, it looks to me like reset_filters does
> not provide that functionality (it just removes all filters not named
> {CORE,CONTENT_LENGTH,HTTP_HEADER}).
You're right (switches b
sterling wrote:
> What do you mean by HEADERS phase? I guess I don't know enough about the
> ordering requirements of the filters.
The AP_FTYPE_HTTP_HEADERS phase (sorry - I shortened it).
> What i did to temporarily fix the problem in my tree was add the
> add_output_filter("HTTP_HEADER"...)
sterling wrote:
> After debugging the problem that doug brought up (headers are not getting
> sent out when there is an error) I noticed that the HTTP_HEADER filter is
> now added in the insert filters phase, which is too late because if there
> is an error in anything from auth to fixups the hea
[EMAIL PROTECTED] wrote:
> > It seems that only certain headers are sent on these responses, all
> > others are stripped. Is this a requirement of HTTP? Can anyone explain
> > why this is like this?
>
> section 10.3.5 of RFC 2068 spells out exactly which heads SHOULD and
> SHOULD NOT, and MUST a
(I'm reposting this, I think it fell through the cracks)
[EMAIL PROTECTED] wrote:
> > How about a new hook for adding AP_FTYPE_HTTP_HEADER filters?
>
> IMO, this should be fixed by adding the three filters above in a
> core_insert_filter phase. Then, mod_headers can easily be run before the
>
Kwindla Hultman Kramer wrote:
> To push this a little further: it could be nice to be able to use both
> environment variables and mod_rewrite-style connection info variables
> as part of the Header directive's set-string. Perhaps something like:
>
> RequestHeader set Language %{ENV:
Ian Holsman wrote:
> what about the case where you need to change the header based on a environment
> variable set in mod_include before the request to the proxy.
>
> eg..
>
> ..
>
>
>
>
> ..
>
> can this kind of thing be done via input-filters/mod_header??
> I put a patch in for a specifi
Greg Stein wrote:
> > I posted a patch to fix this.
>
> Moving the insertion of those filters to the insert_filters hook is the
> right thing to do! Don't get me wrong.
Cool - I'll commit the change later tonight when I have some time...
> I was trying to point out that we've got a lot of flex
Greg Stein wrote:
> If filter types are equal, then order is dependent upon insertion, which
> falls back to the insert_filter ordering.
>
> So... you can correct your filtering ordering by adjusting its type and
> inserting it whenever, or you can have the same type as the core filters and
> ju
[EMAIL PROTECTED] wrote:
> > How about a new hook for adding AP_FTYPE_HTTP_HEADER filters?
>
> IMO, this should be fixed by adding the three filters above in a
> core_insert_filter phase. Then, mod_headers can easily be run before the
> core's insert_fitler phase. Problem solved.
The attached
[EMAIL PROTECTED] wrote:
> > How about a new hook for adding AP_FTYPE_HTTP_HEADER filters?
>
> IMO, this should be fixed by adding the three filters above in a
> core_insert_filter phase. Then, mod_headers can easily be run before the
> core's insert_fitler phase. Problem solved.
Trouble is -
[EMAIL PROTECTED] wrote:
> > How about a new hook for adding AP_FTYPE_HTTP_HEADER filters?
>
> IMO, this should be fixed by adding the three filters above in a
> core_insert_filter phase. Then, mod_headers can easily be run before the
> core's insert_fitler phase. Problem solved.
The attached
Ian Holsman wrote:
> What I need to do with mod-proxy is have a method of communicating
> server notes set from mod-include (or wherever) into the request header
> going to the application server, and also setting notes based on the proxy
> response.
>From the mod_headers experience the correct
[EMAIL PROTECTED] wrote:
> > So the question is - which hook should be called to fiddle with the
> > headers after the content generator runs, but before the headers are
> > sent to the network, whether a body exists or not...?
>
> You are using the wrong kind of output filter. Take a look at h
"Roy T. Fielding" wrote:
> I fixed it.
Cool - thanks. Just fixed the docs.
Regards,
Graham
--
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
t
[EMAIL PROTECTED] wrote:
> > So the question is - which hook should be called to fiddle with the
> > headers after the content generator runs, but before the headers are
> > sent to the network, whether a body exists or not...?
>
> You are using the wrong kind of output filter. Take a look at h
Hi all,
This patch updates the mod_headers docs in line with changes to the
headers module.
Regards,
Graham
--
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
Greg Stein wrote:
> > +ap_hook_insert_filter(ap_headers_insert_output_filter, NULL, NULL,
>APR_HOOK_LAST);
> > +ap_hook_fixups(ap_headers_fixup, NULL, NULL, APR_HOOK_LAST);
> > +ap_register_output_filter("FIXUP_HEADERS_OUT", ap_headers_output_filter,
>AP_FTYPE_CONTENT);
> >
Hi all,
The attached patch is the new mod_headers, supporting HeaderIn and
HeaderOut.
The remaining problem with it seems to be that HeaderOut doesn't add
headers to responses without bodies (such as a 304), but this seems to
be a filters problem.
A documentation patch is on it's way too.
Rega
Graham Leggett wrote:
> > The output filters should *always* run, if at least to send an EOS bucket.
> > That EOS is actually what triggers the delivery of the headers to the
> > network (or at least to the CORE filter for output buffering into the next
> > request).
Greg Stein wrote:
> The output filters should *always* run, if at least to send an EOS bucket.
> That EOS is actually what triggers the delivery of the headers to the
> network (or at least to the CORE filter for output buffering into the next
> request).
>
> So if you're not seeing output filte
Greg Stein wrote:
> Right. We have a beta that people can use and test. The point is to get this
> stuff out to users. It would be great to have more features, but we can't
> keep waiting for each person's feature to be completed before whame send it out
> the door. We need to be able to send int
Greg Stein wrote:
> WTF? How is that "yucky"?? The user sees two tarballs: apache and
> apache+proxy. What is the big deal?
The two tarballs are a big deal.
When I as end user see "apache" and then "apache+proxy" I go to the
mailing list and I say "why are there two archives? which one must I
u
[EMAIL PROTECTED] wrote:
> So this filter doesn't need to do anything if there is not body data? If
> there is no body data, then the filters will never be called.
...
> > The input filter needs to run after the headers are read in and put in
> > r->headers, but before the content generator runs
Cliff Woolley wrote:
> The problem I see with this is that, as Ryan points out, the dependencies
> are backwards for this analogy to work. httpd depends upon APR and
> APR-util, and therefore httpd developers KNOW when the two of those
> packages work, or at least work "well enough" for httpd's
[EMAIL PROTECTED] wrote:
> This is backwards. Right now, APR and APR-util are still essentially a
> part of the HTTP server. In reality, those projects are going to start
> doing their own releases. We haven't solved this problem yet for the web
> server. Making the proxy work like APR and AP
Ian Holsman wrote:
> I've got the 2.0.18 (+proxy) running on Solaris 2.8
>
> Reverse Proxying is working
> I'm seeing some problems going to apple.com and cnet.com (the akamai thing)
> I don't think this should hold up building a single tarball, we just need
> to stick a note that akamized sites
Hi all,
I'd like to nail the whole proxy issue once and for all.
I suggest that we follow the same release procedure for proxy as we do
for apr and apr-util.
Why?
- We know it works.
- The RM knows how to do it already.
- The APR people don't have to do anything other than make sure their
stuf
Greg Stein wrote:
> Even better, the proxy guys should say "okay. we have verified that our
> stuff works with the 2.0.18 tarball, so let's release an apache+proxy
> tarball."
Really yuck for the end user.
There should be just one archive out there. There is no point in
releasing an archive wit
Bill Stoddard wrote:
> Third, we have not decided the best way to
> distribute the proxy. It has been discussed at length but I don;t recall a
> final decision (I really have no opinions on whether the proxy is included
> in the httpd-2.0 tree or not). It is not a big deal to roll the proxy
> ta
Bill Stoddard wrote:
> http://dev.apache.org/dist
>
> Looking for votes to declare this a beta.
Hmm - no proxy in there. :( Can it be added? If so - what needs to be
done to do it?
Regards,
Graham
--
-
[EMAIL PROTECTED]"There's a moon
[EMAIL PROTECTED] wrote:
> If it isn't running, then try changing the filter type. The general
> problem is how we order filters. I am 99.9% sure that the way we link
> request_filters with connection_filters is just plain wrong, but I haven't
> had time to really look at it yet. I would bet t
Bill Stoddard wrote:
> > This doesn't work - the filter is inserted, but it never runs.
>
> Read Ryan's response carefully (and my earlier responses this AM). The
> input filter can filter the request body (not headers).
When I say "filter the headers" I mean "fiddle with the contents of
r->he
[EMAIL PROTECTED] wrote:
> Installing a filter that deals strictly with body data can be done during
> the insert_filter phase. This is where output filters are commonly
> inserted into the chain. Since this is always called before the handler
> phase, we are alright.
This doesn't work - the f
Bill Stoddard wrote:
> I think we have a good shot at a beta candidate. I plan to tag the tree
> early this afternoon (ET) unless I hear objections.
Can we get a proxy in the beta?
Regards,
Graham
--
-
[EMAIL PROTECTED]"There's a moon
Bill Stoddard wrote:
> I am getting a bit more insite into this problem. If you want to add input
> filters, you need to do it with the pre_connection hook, not the
> insert_filters hook. The insert_filters hook is really only useful for
> output filters. This sould be a nice bit of info do docu
Bill Stoddard wrote:
> The new mod_header looks pretty good. +1 for commiting it provided we either
> enable Apache to allow modules to insert input filters or we remove the
> HeaderIn stuff from mod_header.
The HeaderIn stuff was originally a feature request for mod_proxy, where
people could mo
Bill Stoddard wrote:
> YES! I had this on my todo list as well and will gladly review whatever you
> come up with.
I posted a file containing a new mod_headers.c in it (easier to review
than a patch, the module is really small). The output filter works for
me, but the input filter does not - the
Hi all,
Here is a first stab at filterizing mod_headers. I've taken out the
Header directive, and replaced it with HeaderIn and HeaderOut.
HeaderOut seems to work OK, but HeaderIn doesn't - for some reason the
filter gets added with ap_add_input_filter(), but the filter itself
never runs. I've b
RCHAPACH Rochester wrote:
> Sorry if this is sent twice. I'm not sure my previous post got sent out.
>
> Is there a tarball somewhere with the Apache 2.0 proxy code?
Not that I know of - the latest version is available in CVS under the
name httpd-proxy. Simply copy the contents of httpd-proxy/
Bill Stoddard wrote:
> > Would anyone mind if I started hacking at mod_headers for a bit? What
> > I'd like to do is turn it into a filter, and allow it to fiddle with
> > both incoming and outgoing headers
>
> YES! I had this on my todo list as well and will gladly review whatever you
> come up
Fabien Penso wrote:
> So all the .php3 files are send to another apache which has PHP3
> support. But the proxy request inside mod_rewrite doesn't use
> proxy_add_forward and I don't see the original IP at all, which brings
> trouble as the PHP3 then see my local IP as REMOTE_HOST...
Isn't the p
Ian Holsman wrote:
> is there a way to specify a incoming filter for a reverse
> proxy request in the current config command structure?
>
> we intend and doing something similliar to what kwindla's patch does,
> but were going to ad header lines based on a prefix of notes in the notes table
> (
Hi all,
There has been some discussion on the proxy list about a patch that
allows request and response headers to be modified based on config
directives for proxy requests.
Ideally though, header fiddling should be done in mod_headers and be
available to all of Apache, not just the proxy.
Woul
Greg Stein wrote:
> I need to ponder a bit on the exact form of (2), but I'm thinking this is
> the point to merge HTTP_IN and DECHUNK (as we discussed at Hackathon); the
> combined filter would also perform task (2).
The proxy_http module uses the DECHUNK filter - but only because it has
code t
[EMAIL PROTECTED] wrote:
> > Wasn't this change veto'ed? There was a problem about filters that alter
> > the length of the content going through them.
>
> There was no official veto, I just explained why it won't work. :-)
So what will work...? ;)
Regards,
Graham
--
Chuck Murcko wrote:
> Httpd is getting huge when you count all the support projects it
> includes. I think we're moving in the wrong direction keeping it as a
> monolithic release.
I'm thinking in terms of someone who has had to maintain an Apache +
extra modules before. It may make life easier
[EMAIL PROTECTED] wrote:
> Log:
> Track Greg's change to byte count for input filters
Wasn't this change veto'ed? There was a problem about filters that alter
the length of the content going through them.
Regards,
Graham
--
-
[EMAIL PROTECTED]
Greg Stein wrote:
> Instead, you release an httpd. *THEN* the modules ensure they work with
> *that* released version. The modules have a solid, fixed target to shoot
> for. *THEN* you release a rollup.
I am not convinced any more that keeping modules like proxy and rewrite
separate is a good id
Greg Stein wrote:
> Bleck. That is exactly what I was trying to say we *don't* do. That is just
> adding a bunch of overhead onto the RM. Just as we got the RM's job all nice
> and simple, this goes and monkeys it back up.
Ok, stepping back a bit - I am not making myself clear at all. What I'm
p
Greg Stein wrote:
> Ah. I think I understand where you're going. There are two RMs:
>
> 1) the httpd RM (releasing the bare bones httpd)
> 2) the "rollup" RM (releasing httpd + many modules)
>
> At the moment, RM2 only yanks in mod_proxy.
Almost - but there should only ever be one release of A
Chuck Murcko wrote:
> OK, but we still need to maintain the old releases somehow other than as
> CVS tags, no? I.e.; where does the packaged 1.3.19 proxy distribution go
> when we move on to 1.3.20?
Not necessarily - if you're looking for the version shipped with
apache-1.3.19, just look in the
Chuck Murcko wrote:
> 1) tag releases of httpd subprojects intended for release with the
> tagname
> that httpd uses for the same release (simplifies CVS assembly of src)
>
> 2) packaged release drops go into a subdir named by the httpd release
> they go
> with; i.e., httpd, so httpd-pro
Hi all,
After the whole integrate-mod-proxy discussion died down, much was
suggested about a rolldown tree where the latest stable version of a
module was available when an RM wanted to make a release of Apache. This
would require two steps:
- the mod_proxy people (us) would need to create a dir
Ben Laurie wrote:
> Sorry for the delay - the intent of mod_tls is to provide filters for
> all SSL/TLS use in Apache - however, it is more subtle than you think -
> SSL is not symmetric, so several things have to be done differently when
> you are using it for a client as opposed to when it is b
Rodent of Unusual Size wrote:
> > Current status follows, not much to add except for testing/fixing
> > continues...
>
> Should I add this to my weekly automail of the various STATUS
> files?
If you can, please :)
Regards,
Graham
--
-
[EMAIL PROTECTED]
Chris Pepper wrote:
> The problem here is that that doesn't scale. If we have 3
> almost-core modules, users get apache, apache+a, apache+b, or
> apache+c -- the combo builds are useless if you want two or three
> add-ons. I will probably just want SSL, but it doesn't seem wise to
> assum
Greg Stein wrote:
> In fact, jettisoning it from httpd is (IMO) the only reason that we've seen
> *any* activity on it the past couple months.
Nope - the main reason is that for the last month or so I had made
arrangements to work on the proxy full time, something I was not able to
do before bec
[EMAIL PROTECTED] wrote:
> Can you please put some kind of context in your posts. It is absolutely
> impossible to follow a thread like this. :-)
No need - just beat him with a stick! :)
Regards,
Graham
--
-
[EMAIL PROTECTED]"There's a
[EMAIL PROTECTED] wrote:
> Log:
> Sometimes, boys and girls, pointers and integers *aren't interchangeable.
Oops :( Didn't read the definition properly - still rebuilding my
sandbox with everything updated...
Regards,
Graham
--
-
[EMAIL PROTECTED]
Hi all,
Does anyone know if a version of mod_gzip exists for Apache v2.0?
Regards,
Graham
--
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
ton
[EMAIL PROTECTED] wrote:
> + * @param readbytes How many bytes to read from the next filter. 0 means that
> + * a single line should be read.
> */
>AP_DECLARE(apr_status_t) ap_get_brigade(ap_filter_t *filter, apr_bucket_brigade
>*bucket,
>
Ian Holsman wrote:
> what would be really cool would be if modules.apache.org had
>
> a) a categorization tree (so you could drill down)
> b) a method of grabbing 'all' the modules out there
Remember that not all modules are created equal - I would only install
the modules I needed, and only af
Chuck Murcko wrote:
> I think nobody answered because this is pretty obviously the next Right
> Thing to do in distributing httpd and we're to embarassed to admit we
> didn't think of it first. 8^)
Trouble is - we're getting ahead of ourselves. These are all great
ideas, and should be acted on,
dean gaudet wrote:
> how does that work when the browser is making a byterange request on a
> massive object... does the proxy strip the byterange before sending to the
> upstream?
>
> if so... ew.
>
> it would seem the proxy needs to do byteranges (including caching of
> partial content)... or
1 - 100 of 157 matches
Mail list logo
