On 08/ 5/10 01:20 PM, [email protected] wrote:
Hi Brock,
I'm just looking at the transport parts for now.
On Wed, Aug 04, 2010 at 09:25:18PM -0700, Brock Pytlik wrote:
Greetings all,
Here's the webrev for the manifest signing changes:
http://cr.opensolaris.org/~bpytlik/ips-11611-v4/
Transport has been changed to merge with the other recent changes to
transport.
The client-side stuff you've added looks good. I hope the changes to
add the file-path were pretty straight-forward.
Now that I've changed __gen_repo() you actually now have the ability to
enable repo.get_datastream() and repo.get_files() to use either file/0,
or file/1, depending upon which version is available. If you tell
__gen_repo to return origins that support either [0, 1] and pass the
version number as an argument to get_datastream and get_files, these
methods should just work, since file/1 and file/0 are equivalent for
GET.
On the depot side, I have some additional concerns about file/1. In
particular, we enable certain operations based upon what mode the depot
is in. There's a map for everything, a map for read-only, and a map for
mirror mode. In the case of POST file/1, it looks like this operation
is enabled even if the depot is in readonly or mirror mode. At a
Which doesn't really matter as the repository class raises an exception
if mirror or readonly mode is active. And the code in depot.py in this
webrev catches the RepositoryError exceptions when add_file() is called
and returns an appropriate response.
With that said, it could catch RepositoryMirrorError and
RepositoryReadOnlyError and raise a FORBIDDEN http error instead of a
BAD_REQUEST error.
If the server returns a 403, transport shouldn't retry the operation
(per the HTTP/1.1 spec).
minimum, we need to make sure that you can't POST a file in these modes.
That's already been done.
I'm also a bit concerned about how we determine whether POST for file/1
is enabled by the client. Up to this point, the versions/0 information
tells us whether the depot supports a particular operation, and what
versions are supported. If a depot isn't providing a particular
operation, the operation string is absent in the versions/0 information.
However, with file/1, we can support GET file/1, but not POST file/1.
The versions/0 information doesn't currently have a way of expressing
this. Shawn may not agree with me, but perhaps add_cert, or whatever
you had before, is actually preferable? Thoughts?
add_cert isn't preferable was we ultimately need a generic file upload
mechanism anyway, which is all that's being done here. There's nothing
about this operation that makes it specific to certs.
I don't think it's desirable to have a separate operation for every
possible variant of an existing operation. And as I've mentioned
before, from an HTTP standpoint, it makes more sense to support PUT,
GET, etc. for a single part of the namespace and reject operations as
appropriate.
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
