Fix for Issue #8

[blangel]

Includes test case demonstrating the issue.

[buildhive]

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

[buildhive]

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

[swankjesse]

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]

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]

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]

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]

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

[buildhive]

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

[swankjesse]

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

[swankjesse]

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: https://github.com/JakeWharton/DiskLruCache/pull/9#issuecomment-7510385

[blangel]

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]

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]

Makes sense.