On Wednesday 10 October 2007 23:44:03 Roy T. Fielding wrote:
On Oct 10, 2007, at 7:08 AM, Aleksey Midenkov wrote:
On Wednesday 10 October 2007 18:04:47 Jim Jagielski wrote:
On Oct 10, 2007, at 9:38 AM, Aleksey Midenkov wrote:
And resolution for those who will suffer can be
SetEnvIf
[Graham Leggett:]
| It would be nice to have different modules for reverse proxy and forward
| proxy.. from an FTP perspective.
|
| There is a fairly large difference in FTP (and perhaps in other protocols
| too) in terms of the optimizations that needs to be done for forward proxy
| and
[Graham Leggett:]
| It would be nice to have different modules for reverse proxy and forward
| proxy.. from an FTP perspective.
|
| There is a fairly large difference in FTP (and perhaps in other protocols
| too) in terms of the optimizations that needs to be done for forward proxy
| and
On Thu, October 11, 2007 12:53 pm, rahul wrote:
True, my point is that these choices are distributed all over the code.
While it can certainly be run together, it would be much cleaner to have
different modules with emphasis on different things while using a common
ftp_util base for things
While building apache source on AIX5.3 when I give ./configure command
following message is shown.
Checking for DSO...
checking for NSLinkModule... no
checking for shl_load in -ldld... no
checking for dlopen... yes
checking for dlsym... yes
Will NSLinkModule and shl_load in -ldld create
[Graham Leggett:]
| True, my point is that these choices are distributed all over the code.
| While it can certainly be run together, it would be much cleaner to have
| different modules with emphasis on different things while using a common
| ftp_util base for things that are similar.
| The
On Wednesday 10 October 2007 18:46:15 Jim Jagielski wrote:
Or how about leaving the vast majority of the public completely
unaffected and creating a new envvar for those who have problems
with the 10 year old implementation...
If, however, you come up with a complete patch, including docs,
On Thu, October 11, 2007 2:41 pm, rahul wrote:
In the case of a forward proxy you cant expect to get any of these
information from the configuration. So you start with the most general
assumption, and if it fails, you try the next one by interrogating the
server. The requirement of highest
On Oct 11, 2007, at 12:55 AM, Aleksey Midenkov wrote:
This is all irrelevant. No current installation should need any of
those env variables set. They exist solely for working around old
versions of old clients that no longer exist on the net.
Not all... We need mod_proxy responding exactly
On Oct 11, 2007, at 3:12 PM, Ruediger Pluem wrote:
On 10/11/2007 04:12 PM, [EMAIL PROTECTED] wrote:
Author: jim
Date: Thu Oct 11 07:12:02 2007
New Revision: 583829
URL: http://svn.apache.org/viewvc?rev=583829view=rev
Log:
Add fix for, as of now, unconfirmed issue...
Modified:
On Thu, Oct 04, 2007 at 11:52:03AM +0100, Nick Kew wrote:
On Thu, 04 Oct 2007 11:27:30 +0200
Ruediger Pluem [EMAIL PROTECTED] wrote:
I think you should move it to http_filters.c. There are a bunch
of static functions that you can use for creating the header strings
and all this stuff
Hi --
A couple of months ago a short thread started in relation to the
PRs #16593 and #38034 (which also references #42987) on the various
problems related to ETags:
http://marc.info/?l=apache-httpd-devm=118831732512678w=2
http://issues.apache.org/bugzilla/show_bug.cgi?id=16593
Hi,
There is a way we can avoid code duplication of ap_meets_conditions()
- handle the cases that ap_meets_conditions() does not handle
separately. For this, we can create a new dav_meets_conditions() which
calls ap_meets_conditions() and also handles those other cases. Also,
the problem of ETag
Hi --
1) Per #38034, it appears that ap_meets_conditions() treats * incorrectly.
More precisely, I should say that ap_meets_conditions() isn't designed
to support the NULL resources of RFC 2518 (WebDAV). I'm certainly no
expert on these issues, so guidance is welcome.
RFC 2616 section
14 matches
Mail list logo
