Free Windows compilers
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 Windows 2000 Service Pack 4 Windows XP Service Pack 2 Windows Server 2003 Service Pack 1 Windows x64 editions Windows Vista /quote Visual Studio Express http://msdn.microsoft.com/vstudio/express/ Jeff
Re: Free Windows compilers
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 desist now. Final warning. Bill (*) If you had simply quoted the C product which these various projects can use, and pointed out that APR/Apache would build on them, that would have elevated you from a spammer to someone posting relevant information. As none of these projects use other languages, the rest was entirely off topic for these lists. Jeff White wrote: quote [snip] /quote Visual Studio Express http://msdn.microsoft.com/vstudio/express/ Jeff
Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2
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 after uploading the file the MD5 still the same. Did you call it with the same block size as you are using in your code? The '\r' character must appear in the file right at the readBlockSize boundary. YES I ran it with generate_file(offset=-1, readBlockSize=116, fname='testfile') and the MD5 of the input and output files match. ie. generate_file(offset=-1, readBlockSize=116, fname='testfile') Jim PS. Please make sure you cc. python-dev when replying. It's best to keep discussion on the list.
Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2
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
Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2
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 the
current version is 'cur'. Run it and see what happens.
Jim
$ ./upload_test_harness
generate_embedded_cr_file
test offset -1 chunk []
src 5a63347d1106afdfa264b2a61f81ae82
cur 5a63347d1106afdfa264b2a61f81ae82 PASS
new 5a63347d1106afdfa264b2a61f81ae82 PASS
test offset -1 chunk ['CR']
src 82204e52343d5b25c2e783cd59499973
cur e4af2eee73029642a114697ba59217b3 FAIL
new 82204e52343d5b25c2e783cd59499973 PASS
generate_split_boundary_file
test offset -1 chunk []
src d481990a0f0bbd8acf847cd732714555
cur d481990a0f0bbd8acf847cd732714555 PASS
new 8fa5ac9f913d778575ea871506c392a9 FAIL
test offset -1 chunk ['CR']
src 8fa5ac9f913d778575ea871506c392a9
cur d481990a0f0bbd8acf847cd732714555 FAIL
new 8fa5ac9f913d778575ea871506c392a9 PASS
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')
block_size = readBlockSize + offset
f.write('b'*block_size)
f.close()
Then I uploaded 'testfile' using the following
StorageField.read_to_boundary() method:
def read_to_boundary(self, req, boundary, file):
''' read from the request object line by line with a maximum size,
until the new line starts with boundary
'''
previous_delimiter = ''
while 1:
line = req.readline(116)
if line.startswith(boundary):
break
if line.endswith('\r\n'):
file.write(previous_delimiter + line[:-2])
previous_delimiter = '\r\n'
elif line.endswith('\r') or line.endswith('\n'):
file.write(previous_delimiter + line[:-1])
previous_delimiter = line[-1:]
else:
file.write(previous_delimiter + line)
previous_delimiter = ''
And the md5 in the client is the same one as in the server. Do you
have different results? Let me know.
Regards,
/amn
On Nov 7, 2005, at 2:11 PM, Jim Gallacher wrote:
Jim Gallacher wrote:
Alexis Marrero wrote:
Jim,
Thanks for sending the function that creates the test file. However
I ran it to create the test file, and after uploading the file the
MD5 still the same.
Just to clarify, is this for your new read_to_boundary or the one in
3.2? If it's for yours then the MD5 sum *should* be the same, since
that's what you fixed. :)
Did you call it with the same block size as you are using in your
code? The '\r' character must appear in the file right at the
readBlockSize boundary.
ie.
generate_file(offset=-1, readBlockSize=116, fname='testfile')
#!/usr/bin/env python
from mkfile import generate_split_file, generate_file
import sys
from StringIO import StringIO
import md5
def read_to_boundary_current(self, req, boundary, file, readBlockSize):
''' currrent version '''
#
# Although technically possible for the boundary to be split by the read, this will
# not happen because the readBlockSize is set quite high - far longer than any boundary line
# will ever contain.
#
# lastCharCarried is used to detect the situation where the \r\n is split across the end of
# a read block.
#
delim = ''
lastCharCarried = False
last_bound = boundary + '--'
roughBoundaryLength = len(last_bound) + 128
line = req.readline(readBlockSize)
lineLength = len(line)
if lineLength roughBoundaryLength:
sline = line.strip()
else:
sline = ''
while lineLength 0 and sline != boundary and sline != last_bound:
if not lastCharCarried:
file.write(delim)
delim = ''
else:
lastCharCarried = False
cutLength = 0
if lineLength == readBlockSize:
if line[-1:] == '\r':
delim = '\r'
cutLength = -1
lastCharCarried = True
if line[-2:] == '\r\n':
delim += '\r\n'
cutLength = -2
elif line[-1:] == '\n':
delim += '\n'
cutLength = -1
if cutLength != 0:
file.write(line[:cutLength])
else:
file.write(line)
line = req.readline(readBlockSize)
lineLength = len(line)
Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2
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'):
file.write(previous_delimiter + line[:-2])
previous_delimiter = '\r\n'
elif line.endswith('\r'):
file.write(previous_delimiter + line[:-1])
previous_delimiter = '\r'
elif line.endswith('\n'):
if len(line[:-1]) 0:
file.write(previous_delimiter + line[:-1])
previous_delimiter = '\n'
else:
previous_delimiter += '\n'
else:
file.write(previous_delimiter + line)
previous_delimiter = ''
This new functions passes the test for Jim's filetest generator.
[core:~] amarrero% python filegenerator.py ; md5 testfile ; cp
testfile testfile.new ; python test.py ; md5 test.bin
MD5 (testfile) = d481990a0f0bbd8acf847cd732714555
MD5 (outputtestfile.bin) = d481990a0f0bbd8acf847cd732714555
I'm running a test with my set of files (6+) to see any other new
issues.
On Nov 7, 2005, at 6:35 PM, Jim Gallacher wrote:
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 the
current version is 'cur'. Run it and see what happens.
Jim
$ ./upload_test_harness
generate_embedded_cr_file
test offset -1 chunk []
src 5a63347d1106afdfa264b2a61f81ae82
cur 5a63347d1106afdfa264b2a61f81ae82 PASS
new 5a63347d1106afdfa264b2a61f81ae82 PASS
test offset -1 chunk ['CR']
src 82204e52343d5b25c2e783cd59499973
cur e4af2eee73029642a114697ba59217b3 FAIL
new 82204e52343d5b25c2e783cd59499973 PASS
generate_split_boundary_file
test offset -1 chunk []
src d481990a0f0bbd8acf847cd732714555
cur d481990a0f0bbd8acf847cd732714555 PASS
new 8fa5ac9f913d778575ea871506c392a9 FAIL
test offset -1 chunk ['CR']
src 8fa5ac9f913d778575ea871506c392a9
cur d481990a0f0bbd8acf847cd732714555 FAIL
new 8fa5ac9f913d778575ea871506c392a9 PASS
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')
block_size = readBlockSize + offset
f.write('b'*block_size)
f.close()
Then I uploaded 'testfile' using the following
StorageField.read_to_boundary() method:
def read_to_boundary(self, req, boundary, file):
''' read from the request object line by line with a maximum
size,
until the new line starts with boundary
'''
previous_delimiter = ''
while 1:
line = req.readline(116)
if line.startswith(boundary):
break
if line.endswith('\r\n'):
file.write(previous_delimiter + line[:-2])
previous_delimiter = '\r\n'
elif line.endswith('\r') or line.endswith('\n'):
file.write(previous_delimiter + line[:-1])
previous_delimiter = line[-1:]
else:
file.write(previous_delimiter + line)
previous_delimiter = ''
And the md5 in the client is the same one as in the server. Do
you have different results? Let me know.
Regards,
/amn
On Nov 7, 2005, at 2:11 PM, Jim Gallacher wrote:
Jim Gallacher wrote:
Alexis Marrero wrote:
Jim,
Thanks for sending the function that creates the test file.
However I ran it to create the test file, and after uploading
the file the MD5 still the same.
Just to clarify, is this for your new read_to_boundary or the
one in 3.2? If it's for yours then the MD5 sum *should* be the
same, since that's what you fixed. :)
Did you call it with the same block size as you are using in
your code? The '\r' character must appear in the file right at
the readBlockSize boundary.
ie.
generate_file(offset=-1, readBlockSize=116, fname='testfile')
#!/usr/bin/env python
from mkfile import generate_split_file, generate_file
import sys
from StringIO import StringIO
import md5
def read_to_boundary_current(self, req, boundary, file,
readBlockSize):
''' currrent version '''
#
# Although technically possible for the boundary to be split by
the read, this will
Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2
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 purpose (the boundary
will be the only thing on that line, otherwise it's not a boundary)
I've built one without any memcpy whatsoever, I've tried it with the
test harnass and it appears equal to the Alexis version (pass all except
the generate_split_boundary_file test):
def read_to_boundary(self, req, boundary, file, readBlockSize=65536):
prevline =
while 1:
line = req.readline(readBlockSize)
if not line or line.startswith(boundary):
if prevline.endswith('\r\n'):
file.write(prevline[:-2])
elif prevline.endswith('\n'):
file.write(prevline[:-1])
break
file.write(prevline)
prevline = line
Alexis Marrero wrote:
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'):
file.write(previous_delimiter + line[:-2])
previous_delimiter = '\r\n'
elif line.endswith('\r'):
file.write(previous_delimiter + line[:-1])
previous_delimiter = '\r'
elif line.endswith('\n'):
if len(line[:-1]) 0:
file.write(previous_delimiter + line[:-1])
previous_delimiter = '\n'
else:
previous_delimiter += '\n'
else:
file.write(previous_delimiter + line)
previous_delimiter = ''
This new functions passes the test for Jim's filetest generator.
--
Mike Looijmans
Philips Natlab / Topic Automation
Re: cache trouble (Re: [vote] 2.1.9 as beta)
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 configure mod_cache to run as a quick-handler, or a normal-handler. It puts the burden of breaking standards onto the Admin. +1 -- Nick Kew
Re: cache trouble (Re: [vote] 2.1.9 as beta)
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 accomplish is to cause this problem of a downstream cache not knowing that there is access control. If you don't want access control, then don't use access control. Roy
Would like to do 2.2.0-RC1 next week....
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. Thanks, Paul Querna
Re: Would like to do 2.2.0-RC1 next week....
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 following release processes of 2.1.8-beta and 2.1.9-beta, and I'm very looking forward to (finally) seeing a 2.2.x out. If you need some help of any kind for this RC, just ping. - Sam -- Maxime Petazzoni (http://www.bulix.org) -- gone crazy, back soon. leave message. signature.asc Description: Digital signature
Free Windows compilers
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 Windows 2000 Service Pack 4 Windows XP Service Pack 2 Windows Server 2003 Service Pack 1 Windows x64 editions Windows Vista /quote Visual Studio Express http://msdn.microsoft.com/vstudio/express/ Jeff
Re: cache trouble (Re: [vote] 2.1.9 as beta)
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 'faking' a header out of remote-ip. Why? All you accomplish is to cause this problem of a downstream cache not knowing that there is access control. If you don't want access control, then don't use access control. 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 should be able to use. So I agree with Paul that it should be configurable. Regards Rüdiger
Re: cache trouble (Re: [vote] 2.1.9 as beta)
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 should be able to use. Forward proxies using access control use the Proxy-Authenticate header, which is entirely different access control to the WWW-Authenticate header used in normal access control. The Cache-Control: private header would not apply in this case. So I agree with Paul that it should be configurable. Thinking about this for a bit, I don't think it should be configurable. Adding Cache-Control: private to access controlled resources is part of RFC2616, and this spec shouldn't be overriden lightly. 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. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: cache trouble (Re: [vote] 2.1.9 as beta)
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 number of clients on your LAN should be able to use. Forward proxies using access control use the Proxy-Authenticate header, which is entirely different access control to the WWW-Authenticate header used in normal access control. The Cache-Control: private header would not apply in this case. So I agree with Paul that it should be configurable. Thinking about this for a bit, I don't think it should be configurable. Adding Cache-Control: private to access controlled resources is part of RFC2616, and this spec shouldn't be overriden lightly. 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 even for the DEFAULT configuration of apache, we should be sending cache-control private, for EVERY page served. That is bad. bad bad bad bad bad bad bad bad bad bad bad. Did I mention that is bad? We need a better solution. This also implies that if we you use mod_rewrite based on any non-Varied-Header information, you should be setting Cache-Control: Private too. -Paul
Re: Would like to do 2.2.0-RC1 next week....
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 alpha but against ga. So 2 GA votes + 2 Beta votes + 1 alpha vote would fly as a beta release (4 for, 1 against). Once it has the necessary GA votes, simply rebranch the exact beta tag, bump the version and we are released. Bill Paul Querna wrote: 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. Thanks, Paul Querna .
Re: cache trouble (Re: [vote] 2.1.9 as beta)
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 even for the DEFAULT configuration of apache, we should be sending cache-control private, for EVERY page served. Why? This also implies that if we you use mod_rewrite based on any non-Varied-Header information, you should be setting Cache-Control: Private too. No, you should be setting Vary: * if the content varies. That is also required by HTTP. The default in all cases should be HTTP-compliant. You can define additional directives for overriding compliance by consent of the owner, but we shouldn't ship a server that doesn't work correctly by default. Roy
Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2
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')
block_size = readBlockSize + offset
f.write('b'*block_size)
f.close()
Then I uploaded 'testfile' using the following
StorageField.read_to_boundary() method:
def read_to_boundary(self, req, boundary, file):
''' read from the request object line by line with a maximum size,
until the new line starts with boundary
'''
previous_delimiter = ''
while 1:
line = req.readline(116)
if line.startswith(boundary):
break
if line.endswith('\r\n'):
file.write(previous_delimiter + line[:-2])
previous_delimiter = '\r\n'
elif line.endswith('\r') or line.endswith('\n'):
file.write(previous_delimiter + line[:-1])
previous_delimiter = line[-1:]
else:
file.write(previous_delimiter + line)
previous_delimiter = ''
And the md5 in the client is the same one as in the server. Do you
have different results? Let me know.
Regards,
/amn
On Nov 7, 2005, at 2:11 PM, Jim Gallacher wrote:
Jim Gallacher wrote:
Alexis Marrero wrote:
Jim,
Thanks for sending the function that creates the test file.
However I ran it to create the test file, and after uploading the
file the MD5 still the same.
Just to clarify, is this for your new read_to_boundary or the one
in 3.2? If it's for yours then the MD5 sum *should* be the same,
since that's what you fixed. :)
Did you call it with the same block size as you are using in your
code? The '\r' character must appear in the file right at the
readBlockSize boundary.
ie.
generate_file(offset=-1, readBlockSize=116, fname='testfile')
Re: cache trouble (Re: [vote] 2.1.9 as beta)
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 that only a limited number of clients on your LAN should be able to use. Forward proxies using access control use the Proxy-Authenticate header, which is entirely different access control to the WWW-Authenticate header used in normal access control. The Cache-Control: private header would not apply in this case. This is often done via IP addresses and not via username/password. And this is what I think is the real pain and complain: I does not work with IP based access controls. Setting Cache-Control: private is just not what you want here, because this would prevent caching in this case. BTW: RFC2616 says in 14.9.1: private Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache. This allows an origin server to state that the specified parts of the response are intended for only one user and are not a valid response for requests by other users. A private (non-shared) cache MAY cache the response. It talks about *single* users. The problems we are facing here are *groups* of users. So the cache is a shared cache for this group of users in this case. Regards Rüdiger [..cut..]
Re: Free Windows compilers
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 desist now. Final warning. Bill (*) If you had simply quoted the C product which these various projects can use, and pointed out that APR/Apache would build on them, that would have elevated you from a spammer to someone posting relevant information. As none of these projects use other languages, the rest was entirely off topic for these lists. Jeff White wrote: quote [snip] /quote Visual Studio Express http://msdn.microsoft.com/vstudio/express/ Jeff
Re: Would like to do 2.2.0-RC1 next week....
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 beta vote is also a vote for alpha but against ga. So 2 GA votes + 2 Beta votes + 1 alpha vote would fly as a beta release (4 for, 1 against). (And obviously, that's 2 for, 3 against GA, in the example above). Once it has the necessary GA votes, simply rebranch the exact beta tag, bump the version and we are released. What I should have also pointed out that you can call for 2.1.9 to become GA as well, now, if that's what you wish to do. Bill
Re: cache trouble (Re: [vote] 2.1.9 as beta)
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 for now. The compelling reason is that this implies that even for the DEFAULT configuration of apache, we should be sending cache-control private, for EVERY page served. Why? This also implies that if we you use mod_rewrite based on any non-Varied-Header information, you should be setting Cache-Control: Private too. 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. The whole problem here is that Remote-IP is not a request header. It is not accessible through HTTP. And it would be hard to incorporate, because either we trust it and it's trivial to forge, or we enforce it and exclude any client behind NAT. The default in all cases should be HTTP-compliant. You can define additional directives for overriding compliance by consent of the owner, but we shouldn't ship a server that doesn't work correctly by default. If that was the only issue, there wouldn't be a problem. -- Nick Kew
Re: cache trouble (Re: [vote] 2.1.9 as beta)
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 explicitly mentions the network address of the client as an example of server driven negotiation, and that the Vary header can be used for such things :) The whole problem here is that Remote-IP is not a request header. It is not accessible through HTTP. And it would be hard to incorporate, because either we trust it and it's trivial to forge, or we enforce it and exclude any client behind NAT. Content that is variable by IP address should have Vary: * imo, and content that is allowed/denied on a per-IP address basis, should probably have Cache-Control: private. The first is really a problem for server administrators, but the second can be handled by httpd, would it be reasonable to set the header unless there is either no Allow/Deny rules at all, or there is one Allow from all rule and no Deny rules? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: cache trouble (Re: [vote] 2.1.9 as beta)
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 response differs based on IPs unless the Origin says so. -- justin This is true. But in the case of a forward proxy that is used to give office users access to the internet in general based on there IP this is no problem. I do not argue that this behaviour should be the default behaviour of httpd. I completely agree with Roy that httpd by default 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. Regards Rüdiger
Re: cache trouble (Re: [vote] 2.1.9 as beta)
--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. -- justin
Re: cache trouble (Re: [vote] 2.1.9 as beta)
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 case of a forward proxy that is used to give office users access to the internet in general based on there IP this is no problem. Then either the forward proxy has an external agreement with the source (and can override the cache-control) or it has no clue about the source and cannot safely cache the content. In any case, the messages that we send must be correctly marked as private because that is our configuration. If the forward proxy sends a request that has no Cookie and no Authorization, then it is likely that a cache-control private response is indicative of IP-based access control. If you want to code up a forward ProxyCache override based on that, go wild. Roy
Re: cache trouble (Re: [vote] 2.1.9 as beta)
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 Origin says so. -- justin This is true. But in the case of a forward proxy that is used to give office users access to the internet in general based on there IP this is no problem. Then either the forward proxy has an external agreement with the source (and can override the cache-control) or it has no clue about the source and cannot safely cache the content. In any case, the messages that we send must be correctly marked as private because that is our configuration. 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 server). This response would not be cached by mod_cache unless I overwrite it with CacheStorePrivate on. If I set CacheStorePrivate to on the reponse gets cached by mod_cache, but the next request for this (fresh) resource will not check the access control and deliver it to any client, regardless of the IP. Correct? Regards Rüdiger
Re: cache trouble (Re: [vote] 2.1.9 as beta)
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. The compelling reason is that this implies that even for the DEFAULT configuration of apache, we should be sending cache-control private, for EVERY page served. Why? 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? Regards Rüdiger
Re: cache trouble (Re: [vote] 2.1.9 as beta)
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 authentication works completely differently from each other. In a forward proxy configuration, you authenticate access to the proxy using Proxy-Authenticate. Once authenticated you can view cached content. In a reverse proxy (or any normal content) configuration, you authenticate access to content using WWW-Authenticate, and here the Cache-Control: private must be used to make sure that content generated for you is not inadvertently delivered to someone else. Cache-Control: private is not necessary in the forward proxy config. It is necessary in the reverse proxy / normal config case. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: cache trouble (Re: [vote] 2.1.9 as beta)
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 server). No, access control on a forward proxy has nothing to do with cache-control. Cache-control is defined by the origin server. This response would not be cached by mod_cache unless I overwrite it with CacheStorePrivate on. If I set CacheStorePrivate to on the reponse gets cached by mod_cache, Yes, though I would hope that you would set that within a Location directive specific to a given set of URIs. but the next request for this (fresh) resource will not check the access control and deliver it to any client, regardless of the IP. Correct? The forward proxy would deliver it to any client that had the ability to GET from that proxy. Roy
Re: cache trouble (Re: [vote] 2.1.9 as beta)
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 remember which directive applies where, but if the access control is set to deny all and allow some, where some is a locally restricted subset of all, then cache-control private is required on non-error responses unless the request included Authorization (in which case cache-control private is optional because it is already implied with Auth). If the directive is set to allow all and deny some, then it is reasonable to assume that the access control is for service reasons, not authentication, and thus anyone who receives the message should be allowed to cache it for others. It would be wise to make both configurable. Roy
Re: mod_deflate Vary header
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 User-agent or not... there is a risk of getting the wrong content ( compressed versus uncompressed ) stuck in a downstream cache. It is less and less likely these days that the cache will receive a request from a client that CANNOT decompress, but still possible. Handling requests from clients that cannot decompress have become ( at long last ) the fringe cases but are no less important than ever. Actually, with MSIE 5.5+ appearance the chances that client can not decompress the response from downstream cache have increased. If MSIE 5.5 is configured to work via proxy with HTTP/1.0, then MSIE will never send Accept-Encoding header, and it would refuse the compressed content. This is why my mod_deflate for Apache 1.3 by default does not compress response for proxied requests. Microsoft Internet Explorer ( all versions ) will REFUSE to cache anything locally if it shows up with any Vary: headers on it. Period. End of sentence. So you might think you are doing your downstream clients a favor by tacking on a Vary: header to the compressed data so it gets 'stored' somewhere close to them... but you would be wrong. If you don't put a Vary: header on it... MSIE will, in fact, cache the compressed response locally and life is good. The user won't even come back for it until it's expired on their own hard drive or they clear their browser cache. However... if you simply add a Vary: header to the same compressed response... MSIE now refuses to cache that response at all and now you create a thundering herd scenario whereby the page is never local to the user for any length of time and each forward or back button hit causes the client to go upstream for the page each and every time. Even if there is a cache nearby you would discover that the clients are nailing it each and every time for the same page just because it has a Vary: header on it. I believe Netscape has the same problem(s). I don't use Netscape anymore. Anyone know for sure if Netscape actually stores variants correctly in local browser cache? Actually, MSIE 5.5+ will cache the response with any Vary header if it also has Content-Encoding: gzip or Content-Encoding: deflate headers. But it refuses to cache if the response has no Content-Encoding: gzip header. My mod_deflate allows optionally to add Vary header to compressed response only. Igor Sysoev http://sysoev.ru/en/
Re: cache trouble (Re: [vote] 2.1.9 as beta)
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 mod_authz_host could figure out when to stick in
Cache-Control: private on its own.
A possible candidate looks to be in the else block near
mod_authz_host.c:279
else if (a-order[method] == DENY_THEN_ALLOW) {
Placing a config-overridable
apr_table_set(Cache-Control, private);
line in that else block would likely work, I guess. (should that be
apr_table_merge instead?)
Completely untested and clearly not thought through. =) -- justin
