Support for COPY/MOVE methods?

[John Hoerr]

Has there been any consideration of adding first-class support for the COPY and MOVE methods?  I'm currently in need of these and would be happy to work on it.

[Andrew Young]

No consideration has been made, however, copy and move aren't valid request methods.

[John Hoerr]

I agree with you that they're invalid in the sense that they aren't a part of the HTTP 1.1 Spec.  But they are a part of the WebDAV spec (http://www.webdav.org/specs/rfc2518.html.)  They're also necessary for certain cloud storage implementations such SkyDrive (in my particular case.)  It seems like the inclusion of PATCH support would open the door for useful methods like this.

I guess what I'm really asking is, if I were to implement these would there by any chance those changes would be pulled back into the mainline repo?  Barring that, would y'all consider the inclusion of some mechanism for setting an arbitrary HTTP method on the request?  (Or is there perhaps already such a mechanism that I'm not seeing?)

Thanks!

[Andrew Young]

I'm willing to consider it given that its fairly unobtrusive and low maintenance on the existing code base. If it is going to change a lot of the underlying structure it may be met with some resistance. Do you already have an idea of what the implementation would look like?

[John Hoerr]

Cool -- thanks for being open to it.  I'm thinking that both methods will exactly mirror PATCH.  Nothing fancy.  POST-style parameters make sense to me given that you'd have to at least specify a destination.

[John Sheehan]

I don't think we want to clutter IHttp with a bunch of non-standard methods. Is there a way to make this more generic to take in any custom method if it doesn't match the current set?

[John Hoerr]

Yes, I think so.  The Method enum ultimately resolves to a string, so I think there's an opportunity to tie something in there.  I'll work on that tomorrow.  

I submitted a pull request for the new IHttp methods earlier today, and I'm sorta new to git: do y'all reject the request, or do I retract it? 

[John Hoerr]

Ah, I can close it myself.  Done.

[John Hoerr]

I opened Pull Request 316 with my proposed changes, which are limited to the a0f67ed changeset.  I think adding methods IHttp is appropriate because that's where we do the work of determining which HTTP method to execute.

One piece that feels smelly is that RestClient.BuildUri() uses the HTTP method to determine how to configure the request parameters.  This basically boils down GET vs. POST.  Thus, when executing an arbitrary HTTP method such as "COPY", we must still tell the RestClient whether to configure the parameters in the GET- or POST-style.  Thus, we have the AsGet*() and AsPost*() methods on IHttp.  It might be worth figuring out a way for BuildUri to make that determination without relying on the particular method that's being called.  But that seems like a potentially invasive change and I didn't want to go there just yet.