Re: HEAD not well supported?

ected behavior that when using the -X option the behavior not be modified based on what is passed to -X. So using curl -X HEAD results in GET-like behavior (wait for content) with a HEAD method. best, Erik ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpL0UsZaXCKu.pgp Description: PGP signature

Re: HEAD not well supported?

or HEAD request be the same for all resources. Am I misunderstanding you here? best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpa7495zhgap.pgp Description: PGP signature

Re: HEAD not well supported?

e Resource.allowGet() method for both GET and > HEAD requests as there is no reason (following the HTTP spec intent) to > differentiate GET and HEAD request in this regard. > > I'm still convinced that current design is appropriate. I would even go > further by removing the Resource.ha

Re: HEAD not well supported?

007-10-03, Adam Taft wrote: > >You don't need to send 204 because, by definition, HEAD already > >means no content. > >That status code is entirely appropriate for GET requests. And, also, for HEAD requests: if the GET request would also have returned no content. best, Erik Hetzner pgpxC0M0o2gQN.pgp Description: PGP signature

Re: HEAD not well supported?

to HEAD > requests. Could you point these status codes out to me? I can’t figure out which ones you might mean. best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpF6BQICFgBm.pgp Description: PGP signature

Re: HEAD not well supported?

ource > > that allows a GET really should allow a HEAD. > > That was John's point which I agree with. Default is true. Missed that. Thanks. best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpQHBRICgPMF.pgp Description: PGP signature

Re: HEAD not well supported?

onse to the HEAD request should be the same to a GET, so it makes sense to share the logic. Also, intuitively allowHead is a bit redundant, since any resource that allows a GET really should allow a HEAD. best, Erik Hetzner pgpBRvwZrLpJV.pgp Description: PGP signature

Re: Jersey Project?

languages on the JVM. At least, I have had very good experience with Scala & Restlet; I presume that JRuby should also work well. best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpZT2OQCLikH.pgp Description: PGP signature

Re: comments/feedback requested

ith slashes’ following ‘organized hierarchically’. This was an error. This sentence is referring to the entire URI, not just the path segment, so there are number of characters other than / in other parts of the URI which signify hierarchy. In the path part, however, only the / signifies hierarchy.

Re: comments/feedback requested

f you can’t answer that question, and I don’t think that you can, then you don’t have a hierarchy. best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpCKCf52IfJJ.pgp Description: PGP signature

Re: comments/feedback requested

's also congruent > with a web server serving a static folder hierarchy. > > Ultimately, it doesn't matter what your delimiter is. I just think > slashes seem more intuitive for this type of "ordered" or > "hierarchical" usage. It’s not commas vs. sla

Re: 404 from getRepresentation/handleGet?

Some more to do with DELETE: <http://tech.groups.yahoo.com/group/rest-discuss/message/2626> But, you’re right. If we disagree about the definition, we’re not going to get very far. best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpOvbiLr7WDe.pgp Description: PGP signature

Re: comments/feedback requested

chy. Use commas when the order of the | items matters, as it does in latitude and longitude: | /Earth/37.0,-95.2. Use semicolons when the order doesn’t matter: | /color-blends/red;blue. best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpYkbgdaWE5M.pgp Description: PGP signature

Re: 404 from getRepresentation/handleGet?

e-effects of N > 0 identical | requests is the same as for a single request. This means side effects, server state changes, not response bodies or response status codes. best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpiSx2r3jiA8.pgp Description: PGP signature

Re: 404 from getRepresentation/handleGet?

applicable to other protocols. > However, if you follow the HTTP spec and you apply the REST principles > to it, I believe what you end up with is this logical mapping of what > HTTP status codes can be returned for which HTTP methods. For 2xx > only, it goes: > > GET => 200, 206 &

Re: 404 from getRepresentation/handleGet?

ays return 200, because the state of the resource previous to the request is irrelevant. > Anyway, I'm glad you see the point about DELETE. Cheers to that. And thanks again for pointing it out. > Adam > > p.s. My last message was jumbled. Sorry, I was tired. ;) > > p.p.s

Re: 404 from getRepresentation/handleGet?

At Tue, 17 Jul 2007 20:56:48 -0600, Adam Taft <[EMAIL PROTECTED]> wrote: > > Erik Hetzner wrote: > > […] ‘idempotent’ means repeating the operation ends up with the > > resource in the same state (it doesn't mean all the responses are > > always identical). >

Re: 404 from getRepresentation/handleGet?

rolled. >From the Rest wiki: <http://rest.blueoxen.net/cgi-bin/wiki.pl?RestFaq#nid1VU> […] ‘idempotent’ means repeating the operation ends up with the resource in the same state (it doesn't mean all the responses are always identical). best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpWhyJeqsz8K.pgp Description: PGP signature

Re: 404 from getRepresentation/handleGet?

ame actual response. OPTIONS, for instance, should not have side effects, but it has a response. best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpCM8gQJXqyC.pgp Description: PGP signature

Re: 404 from getRepresentation/handleGet?

At Tue, 17 Jul 2007 17:17:19 -0700, "John D. Mitchell" <[EMAIL PROTECTED]> wrote: > > On 7/17/07, Erik Hetzner <[EMAIL PROTECTED]> wrote: > [...] > > You make some really good points; thanks for doing that. I wouldn't > > put this in 'shou

Re: 404 from getRepresentation/handleGet?

Hi Adam, At Tue, 17 Jul 2007 16:51:04 -0600, Adam Taft <[EMAIL PROTECTED]> wrote: > > Erik Hetzner wrote: > > I must have missed this in RFC 2616. How do you propose we tell the > > difference between a DELETE that does something & one that doesn’t? > > Why do yo

Re: 404 from getRepresentation/handleGet?

sed this in RFC 2616. How do you propose we tell the difference between a DELETE that does something & one that doesn’t? best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpCdkYh5QDXh.pgp Description: PGP signature

Re: Setting Content-length in http client request?

lient supports the HTTP protocol. This makes sense. Thanks again for your help. And thanks as well for everybody’s work on Restlet. best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpKB0SdOUZyf.pgp Description: PGP signature

Re: Setting Content-length in http client request?

1.0.2 & expecting an error message, not a silent problem. Many thanks. best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpk7zKcPGV4Q.pgp Description: PGP signature

Setting Content-length in http client request?

ng up of an http client? best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpTR6oPWi61D.pgp Description: PGP signature