Skip to content
This repository has been archived by the owner on Jul 21, 2023. It is now read-only.

Fix for Issue #8 #9

Closed
wants to merge 2 commits into from
Closed

Fix for Issue #8 #9

wants to merge 2 commits into from

Conversation

blangel
Copy link
Contributor

@blangel blangel commented Aug 5, 2012

Includes test case demonstrating the issue.

@buildhive
Copy link

Jake Wharton » DiskLruCache #3 FAILURE
Looks like there's a problem with this pull request
(what's this?)

@buildhive
Copy link

Jake Wharton » DiskLruCache #4 SUCCESS
This pull request looks good
(what's this?)

@swankjesse
Copy link
Collaborator

URL encoding is not the right solution to the problem. Instead the caller should do his own encoding to a format that's legal according to the DiskLruCach documentation. Android's HttpResponseCache uses the URLs MD5 sum, which has the nice property of limiting the URLs length.

@blangel
Copy link
Contributor Author

blangel commented Aug 5, 2012

Delegating the encoding to the user is fine, however, this restriction I don't see documented. What documentation on DiskLruCache are you referencing? Neither the readme nor the javadoc mentions any restriction on the key. The source code has a validateKey method but the validation is only to restrict spaces ' ' and newlines '\r' and '\n'. Perhaps it should validate on '/' characters as well because otherwise DiskLruCache fails unexpectedly when calling 'newInputStream' on an Editor (see added test case method testWriteAndReadEncodedEntry from the pull-request commit).

@swankjesse
Copy link
Collaborator

My bad; the class doesn't document legal keys. It should. Legal keys should match this regex: [a-z0-9_]{1,64}. They shouldn't include non-ASCII characters or care about case preservation, since those attributes are not portable across file systems. Symbolic characters are generally non-portable and should not be used. They should also be relatively short since the names are repeatedly written in metadata and compared with one another.

@blangel
Copy link
Contributor Author

blangel commented Aug 5, 2012

Ok. So I'll close this request and make another with commits which change the validateKey method to check against regex: [a-z0-9_]{1,64}. I'll also document as such and add a test case. Sound good?

@swankjesse
Copy link
Collaborator

That would be awesome. (Jake gets the final say!)

@swankjesse swankjesse closed this Aug 5, 2012
@swankjesse swankjesse reopened this Aug 5, 2012
@buildhive
Copy link

Jake Wharton » DiskLruCache #5 SUCCESS
This pull request looks good
(what's this?)

@swankjesse
Copy link
Collaborator

(Close/Reopen is just me being clumsy using a mobile browser.)

@blangel blangel closed this Aug 5, 2012
@swankjesse
Copy link
Collaborator

Works for me.
On Aug 5, 2012 10:44 AM, "Brian Langel" <
reply@reply.github.com>
wrote:

Ok. So I'll close this request and make another with commits which change
the validateKey method to check against regex: [a-z0-9_]{1,64}. I'll also
document as such and add a test case. Sound good?


Reply to this email directly or view it on GitHub:
#9 (comment)

@blangel
Copy link
Contributor Author

blangel commented Aug 5, 2012

Forcing lower case keys complicates normal usage. Even some of the test cases would need to change and call .toLowerCase() before interacting with DiskLruCache. Perhaps the legal keys should be loosened to [a-zA-Z0-9_]{1,64}, sacrificing some portability for usage. Thoughts?

@swankjesse
Copy link
Collaborator

It's probably worth fixing the test case. Most consumer file systems are case insensitive, and DiskLruCache will behave incorrectly since "A" and "a" are non-equal strings but yield the same files on the file system.

@blangel
Copy link
Contributor Author

blangel commented Aug 5, 2012

Makes sense.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants