On 03/04/12 23:22, Tim Foster wrote:
Hi there,
I've got a change here that improves pkg(1) when sitting behind a web
cache that has somehow been populated with corrupted content.
I wasn't sure whether t_pkg_install was the best place for the test
here, but couldn't see anywhere else in the testsuite that specifically
addresses transport changes - I'm happy to move it there's a better place.
https://cr.opensolaris.org/action/browse/pkg/timf/poisoned-cache/poisoned-cache-webrev/
src/modules/client/transport/repo.py:
line 1034: it should set header["Pragma"] = "no-cache" as well;
that's also true for line 513; necessary for HTTP 1.0 caches [1]
lines 213, 1037, 1752: need extra newline
lines 1750, 2019: I'd make these docstrings the same and something
like: """Pointless to attempt refetch of corrupt content for
this protocol."""
src/modules/client/transport/transport.py:
line 917: this comment is subtly different for each retry case
lines 918-926: so the problems I see with this approach are (and it
applies to most of the other cases):
* it relies on the number of retries left being sufficient
to retrieve the content (i.e. retry_count) that's probably ok,
but there should be a comment
* if this is the last retry already, then the failure
won't be added to failedreqs / failures (oops), a simple
fix for that would be to track the number of retries and
skip the redownload if retries == retry_count
* i'm not sure why it's doing "errlist.append(e)" as
errlist will be re-assigned at the next iteration of the loop
and entries in flist are sufficient to prevent a successful
return
src/tests/cli/t_pkg_install.py:
lines 784-788: instead of this, you can grab the fmri from the list
that pkgsend_bulk returns on line 755
lines 790-791: actually, simply doing a forced image-create again
doesn't clear the content, but our image_create() routine
automatically calls the unit test image_destroy() method
line 800: s/"w"/"wb"/
-Shawn
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss