On Monday 07 November 2005 03:26, Paul Querna wrote:
Cache-control: private
is what should be added for any resource under access control.
I'd prefer something a little less drastic, like 'faking' a header out
of remote-ip.
I still like making it admin configurable. Allowing the admin to
On Nov 7, 2005, at 2:06 AM, Nick Kew wrote:
On Monday 07 November 2005 03:26, Paul Querna wrote:
Cache-control: private
is what should be added for any resource under access control.
I'd prefer something a little less drastic, like 'faking' a header out
of remote-ip.
Why? All you
I would like to do tag 2.2.0-RC1 in the middle of next week. (Like,
Wednesday sounds good right now)
We are getting very few bug reports for 2.1.xx-BETAs. Last week
www.apache.org was switched to run 2.1.9-BETA.
If you know of any show stopping issues, please add them to the
2.2.x/STATUS file.
Hi,
* Paul Querna [EMAIL PROTECTED] [2005-11-07 10:40:40]:
I would like to do tag 2.2.0-RC1 in the middle of next week. (Like,
Wednesday sounds good right now)
We are getting very few bug reports for 2.1.xx-BETAs. Last week
www.apache.org was switched to run 2.1.9-BETA.
+1. I've been
quote
Visual Web Developer 2005 Express Edition
Visual Basic 2005 Express Edition
Visual C# 2005 Express Edition
Visual C++ 2005 Express Edition
Visual J# 2005 Express Edition
SQL Server 2005 Express Edition
Price:
Visual Studio Express Editions -
Free for 1 year
Operating System
On 11/07/2005 07:27 PM, Roy T. Fielding wrote:
On Nov 7, 2005, at 2:06 AM, Nick Kew wrote:
On Monday 07 November 2005 03:26, Paul Querna wrote:
Cache-control: private
is what should be added for any resource under access control.
I'd prefer something a little less drastic, like
Ruediger Pluem wrote:
I agree that there are many situation where it does not make sense to cache
things under access
control, but there are ones where it makes sense.
e.g. If you create a forward proxy with httpd that should use caching and that
only
a limited number of clients on your LAN
Graham Leggett wrote:
Ruediger Pluem wrote:
I agree that there are many situation where it does not make sense to
cache things under access
control, but there are ones where it makes sense.
e.g. If you create a forward proxy with httpd that should use caching
and that only
a limited
The way we did this with 2.0, and I personally believed it worked, would
be to tag 2.1.10 with the expectation that it's GA...
roll it, test it, vote between (alpha, beta, ga). Consider the vote as
as +1 to any lower categories, and -1 to greater ones, such that a beta
vote is also a vote for
On Nov 7, 2005, at 1:01 PM, Paul Querna wrote:
If there is a compelling reason to support not adding Cache-Control:
private to authenticated requests, then it's definitely an option,
but I
think we should default to the safe option for now.
The compelling reason is that this implies that
Ok. Now I'm confused.
What I was trying to say is that I created a file with this function:
def generate_split_file(offset=-1,
readBlockSize=65368,
fname='testfile'):
f = open(fname, 'w')
f.write('a'*50)
f.write('\r\n')
On 11/07/2005 09:48 PM, Graham Leggett wrote:
Ruediger Pluem wrote:
I agree that there are many situation where it does not make sense to
cache things under access
control, but there are ones where it makes sense.
e.g. If you create a forward proxy with httpd that should use caching
and
Hello Jeff...
that's quite enough Spam. You had nothing productive to offer(*) in this
post other than someone elses marketing material. I've pointed this out
to you personally in the past, and you've chosen to ignore my private
comments, so this one is public.
You are publicly asked to
William A. Rowe, Jr. wrote:
The way we did this with 2.0, and I personally believed it worked, would
be to tag 2.1.10 with the expectation that it's GA...
roll it, test it, vote between (alpha, beta, ga). Consider the vote as
as +1 to any lower categories, and -1 to greater ones, such that a
On Monday 07 November 2005 21:10, Roy T. Fielding wrote:
On Nov 7, 2005, at 1:01 PM, Paul Querna wrote:
If there is a compelling reason to support not adding Cache-Control:
private to authenticated requests, then it's definitely an option,
but I
think we should default to the safe option
On Mon, Nov 07, 2005 at 09:28:54PM +, Nick Kew wrote:
No, you should be setting Vary: * if the content varies. That is
also required by HTTP.
That applies if it varies by some request header.
Vary: * means that how the content varies in unspecified, and section
12.1 of RFC2616
On 11/07/2005 10:31 PM, Justin Erenkrantz wrote:
--On November 7, 2005 10:16:34 PM +0100 Ruediger Pluem
[EMAIL PROTECTED] wrote:
[..cut..]
The problem is that without Cache-Control: private, any downstream cache
would have the exact same problem. There's no way for it to know that
the
--On November 7, 2005 11:09:05 PM +0100 Ruediger Pluem [EMAIL PROTECTED]
wrote:
must be HTTP compliant, but there should be possibilties (and there
already are) to
break this compliance with explicit configuration options to get some
things working.
Yes, CacheStorePrivate will do this. --
On Nov 7, 2005, at 2:09 PM, Ruediger Pluem wrote:
The problem is that without Cache-Control: private, any downstream
cache
would have the exact same problem. There's no way for it to know that
the response differs based on IPs unless the Origin says so. --
justin
This is true. But in the
On 11/07/2005 11:30 PM, Roy T. Fielding wrote:
On Nov 7, 2005, at 2:09 PM, Ruediger Pluem wrote:
The problem is that without Cache-Control: private, any downstream cache
would have the exact same problem. There's no way for it to know that
the response differs based on IPs unless the
On 11/07/2005 10:10 PM, Roy T. Fielding wrote:
On Nov 7, 2005, at 1:01 PM, Paul Querna wrote:
If there is a compelling reason to support not adding Cache-Control:
private to authenticated requests, then it's definitely an option, but I
think we should default to the safe option for now.
Ruediger Pluem wrote:
If I have a forward proxy to which I limit access via IP based access control
I should add Cache-Control: private to any response I get back from the backend
(either a Remote Proxy or the origin server).
A very important distinction: forward and reverse proxy
On Nov 7, 2005, at 3:03 PM, Ruediger Pluem wrote:
Just checking if I understood things correctly:
If I have a forward proxy to which I limit access via IP based access
control
I should add Cache-Control: private to any response I get back from
the backend
(either a Remote Proxy or the origin
On Nov 7, 2005, at 3:10 PM, Ruediger Pluem wrote:
Not for every page, but if I get it right once you lock out one bad
boy via
deny ipaddress
than it should be sent. AFAIK this not done automatically currently
once you add a deny
directive somewhere. Does this need to be changed?
I can't
On Fri, 4 Nov 2005 [EMAIL PROTECTED] wrote:
This has been discussed many times before and no one
seems to understand what the fundamental problem is.
It is not with the servers at all, it is with the CLIENTS.
What both of you are saying is true... whether you Vary:
on Content-encoding and/or
On Tue, Nov 08, 2005 at 07:48:07AM +0100, Ruediger Pluem wrote:
So do you think that there is a todo for mod_authz_host to add such things
or should this be left to the administrator who can of course use
mod_headers in the first case to add Cache-Control: private?
It'd be nice if
quote
Visual Web Developer 2005 Express Edition
Visual Basic 2005 Express Edition
Visual C# 2005 Express Edition
Visual C++ 2005 Express Edition
Visual J# 2005 Express Edition
SQL Server 2005 Express Edition
Price:
Visual Studio Express Editions -
Free for 1 year
Operating System
Hello Jeff...
that's quite enough Spam. You had nothing productive to offer(*) in this
post other than someone elses marketing material. I've pointed this out
to you personally in the past, and you've chosen to ignore my private
comments, so this one is public.
You are publicly asked to
Sorry for all this emails, but my system depends 100% on mod_python
specially file uploading. :)
On Nov 7, 2005, at 2:04 PM, Jim Gallacher wrote:
Alexis Marrero wrote:
Jim,
Nicolas,
Thanks for sending the function that creates the test file.
However I ran it to create the test file, and
Alexis Marrero wrote:
Sorry for all this emails,
No worries. It's a bug that needs to be fixed, so your work will benefit
everyone. :)
Jim
Alexis Marrero wrote:
Ok. Now I'm confused.
So am I!
I've created a test harness so we can bypass mod_python completely. It
includes a slightly modified version of read_to_boundary which adds a
new parameter, readBlockSize.
In the output from the test harness, your version is 'new' and
New version of read_to_boundary(...)
readBlockSize = 1 16
def read_to_boundary(self, req, boundary, file):
previous_delimiter = ''
while 1:
line = req.readline(readBlockSize)
if line.strip().startswith(boundary):
break
if line.endswith('\r\n'):
What i don't like at all in this implementation is the large amount of
memcpy operations.
1. line.strip()
2. line[:-x]
3. previous_delimiter + ...
The average pass will perform between two and three memcopy operations
on the read block.
Suggestion: Loose the strip() call - it serves no
33 matches
Mail list logo
