Re: HEAD not well supported?
At Tue, 9 Oct 2007 22:29:19 +0200, "Jerome Louvel" <[EMAIL PROTECTED]> wrote: > Hi all, > > At the lower API level, we don't differentiate the HEAD from the GET > methods, see the org.restlet.Uniform class and subclasses like > Restlet. > > However, at the higher API levels, at the > org.restlet.resource.Resource level especially, we do go further by > adding implicit support for content negotiation, conditional > methods, HEAD implementation based on GET, etc. > > If you want to gain full control, you can always build > Restlet/Filter subclasses. > > However, I agree with the fact that the > Resource.handleGet/handleHead methods are a bit confusing, that's > why we'll move them to the Finder class in 1.1. Thanks for the explanation. As an aside, the developers of curl have indicated that it is the expected 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?
At Mon, 8 Oct 2007 17:35:00 + (UTC), Sean Landis <[EMAIL PROTECTED]> wrote: > Regarding my previous comments regarding a test using curl; it appears curl > is hung up on the fact that content length has a value and there is no > entity. I did determine that Restlet does remove the content. Sorry for being > misleading on that point. It does appear that curl is wrong here. I have filed a bug report at <http://sourceforge.net/tracker/index.php?func=detail&aid=1810273&group_id=976&atid=100976> You can obtain correct behavior by using the -I/--head option instead of -X HEAD, which is good to know. > I'd say that Restlet meets the requirements of the spec and that's > good. Although I still think it would be better to leverage Uniform > entirely and it seems awkward to me that HEAD is an exception. > > My understanding of REST is that HEAD is part of the uniform > interface and therefore should be supported in the same way, and to > the same extent as the rest of the HTTP methods. I was very > surprised when HEAD did not conform to the programming model in > place for the uniform interface and I suspect others would be too. I don’t understand what you mean here by uniform interface. Uniform interface in REST refer to inter-application semantics, not intra-application. And it doesn’t, to my understanding, mean that HEAD & GET must have identical semantics, rather that the semantics of a GET 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?
At Sat, 6 Oct 2007 18:40:36 +0200, "Jerome Louvel" <[EMAIL PROTECTED]> wrote: > Hi all, > > I'm a bit late in the discussion it seems :) > > Let me try to explain how the support for HEAD was designed in Restlet. > Following the definition of HEAD from the HTTP spec [1], I got convinced > that HEAD was only a special GET and nothing more: > > "The HEAD method is identical to GET except that the server MUST NOT return > a message-body in the response." > > In order to fulfill this requirement, the framework expects you (Resource > and any Restlet/Filter/etc.) to return the exact same response as you would > for the similar GET request. > > The trick is that at the HTTP server connector level, we never send back the > response's entity content for HEAD requests. So during the lifecycle of a HEAD request we should never get a call to the write/getStream/getChannel/toString methods of a Representation? If so, a lazy initialization of representation content should be possible. > However, we do need the full Representation because some metadata are not > part of the Variant information per se. I know in Restlet 1.0 the Variant > class do have the "size" property but that was a mistake that we fixed in > version 1.1 (trunk) by moving the property down to the Representation class > (subclass of Variant). The same was done for the "Expiration Date", > "ModificationDate" and "Tag" properties. Looking at the code, I expected that Variant had all those properties to allow for it to be sufficient for a HEAD request, so I was confused that HEAD would use a representation; but this makes sense. > Also, the Finder class calls the 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.handleHead() method and make the Finder > class call handleGet() directly instead. > >[…] Not my place, perhaps, but I am agreed. best, Erik ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpzsSzGTaVM2.pgp Description: PGP signature
Re: HEAD not well supported?
At Thu, 4 Oct 2007 12:03:41 -0700, "Aron Roberts" <[EMAIL PROTECTED]> wrote: > […] >In this discussion, Adam Taft stated his belief that it is > inappropriate to return a 204 status code as part of the response > from a HEAD request: > > At 20:22 -0600 2007-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?
At Wed, 3 Oct 2007 19:39:10 -0700, "Aron Roberts" <[EMAIL PROTECTED]> wrote: > > In the message "Re: HEAD not well supported?", dated 10/3/07, Adam Taft wrote: > >NO! The whole point of HEAD is to emulate a GET request, except > >without returning the message body. You don't need to send 204 > >because, by definition, HEAD already means no content. > >That makes sense: why return a status code indicating explicitly > that no content is to be returned, since that may falsely imply that > content in the entity body is sometimes allowed? > >In that case, then, a status code of 200 would seem to be the only > appropriate success response from an HTTP HEAD request. Status codes > 201 through 203 appear to be inappropriate to HEAD requests, as well. To be pedantic: the status code is NOT part of the message headers, and not then part of the metainformation which should be the same in a HEAD as in a GET, per 2616. But I certainly can’t think of a good reason to have a different status code for a HEAD from a GET. > >A call to HEAD should return _exactly_ the same headers as the same > >call to GET. > >True. Responses to HEAD requests should return the same set of > HTTP headers as responses to GET requests, except for the empty > entity body. > >As a slight refinement, however, responses to HEAD requests should > not always return the range of status codes appropriate to GET > requests. There are certain HTTP status codes are only appropriate > to a specific HTTP method, or a subset of those methods. > Specifically, there are some status codes that are appropriate to be > returned in response to GET requests but not in response 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?
Hi Sean, At Wed, 3 Oct 2007 21:36:57 + (UTC), Sean Landis <[EMAIL PROTECTED]> wrote: > Yes you could but there's already a programming model for dealing > with HTTP methods. One could argue handle*() methods could be final > for example. Why exclude HEAD from that model? Ah, sorry. I haven’t been using the getVariant/getRepresentation/etc. paradigm. Thanks for pointing that out. > > Why should you special case getRepresentation? > > Because HEAD shouldn't necessarily return a representation. Ah, looking further at the API I see what you mean. It does seem that the Variant class should contain all the data that is necessary to send back to the client from a HEAD request (size, mimetype, etc.) It does look as though the default code for a get calls a getRepresentation rather than simply determine the correct Variant, which seems all that is necessary when responding to a HEAD. > […] > Are you saying there's some place in Restlet where the entity is striped > out in the case of HEAD? You might be right, although I didn't see it. > Regardless, that makes unreasonable assumptions about the intent for > HEAD. I don’t know; it just seems to me that the place for the optimization which doesn’t call the code that returns the content of the response when we have a HEAD instead of a GET belongs there, not in a special case in your Resource. > > Also, intuitively allowHead is a bit redundant, since any resource > > 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?
At Mon, 1 Oct 2007 19:28:09 + (UTC), Sean Landis <[EMAIL PROTECTED]> wrote: > > I was implementing HEAD on a resource and couldn't figure out how to do it > so I looked at the source for Resource.handleHead() and was surprised to > see it calls handleGet(). My understanding of HEAD is that it provides > all but the entity. That seems to imply that that getRepresentation() > needs to check what method is used and special case HEAD somehow. That is > awkward and inconsistent with the rest of the method handling paradigm. > > One solution is to provide allowHead() and head(). It might make sense > to implement head() by calling getRepresentation() but this approach > doesn't require it and fits better with the current method handling > style. I don’t understand what the issue is here? Can you not override handleHead? Why should you special case getRepresentation? The representation should be the same. Presumably (correct me if I’m wrong, Restlet authors) when sending a response to a head request back to the client the server simply won’t make a call to get the actual content of the representation. In almost every way the response 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?
At Wed, 22 Aug 2007 19:23:15 +0200, "Jerome Louvel" <[EMAIL PROTECTED]> wrote: > > Hi Justin, > > How did you get the impression that we would be moving to Jersey? > Jersey is the reference implementation of JSR-311 which is under > design by the EG, led by Sun. > > The JSR-311 API is annotation-centric, high-level and server-centric while > the Restlet API is class-centric, both low-level and high-level and both > client-side and server-side. > > […] As a quick aside, the class-centric nature of Restlet makes it a good fit for non-Java 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
At Thu, 19 Jul 2007 13:48:35 -0600, Adam Taft <[EMAIL PROTECTED]> wrote: > Which is greater significance: manufacturer, model year, model class, > model type? You said /cars/ford/2007/f-series/f-150/ was acceptable. > But, you can't answer which is more significant either. They are all > required to uniquely identify the tuple, in this case a truck. I didn’t say it was acceptable as a hierarchy (that is, a good hierarchy), thought it may be. I meant that by using the slash you identify it as a hierarchy. Whether model, manufacturer, etc. is more important is a judgment you make designing your URLs. By using the URL /cars/ford/2007/f-series/f-150/ you suggest that: cars > ford > 2007 > f-series > f-150 In other words, for the f-150, it is most importantly a car, then a ford, then a 2007 model, then an f-series, then an f-150. This is part of the URI generic syntax and the definition of a hierarchy. See: <http://gbiv.com/protocols/uri/rfc/rfc3986.html#hierarchical> Look, here’s an example of what I’m talking about. In binomial nomenclature, E. coli is uniquely identified by the 2-tuple of its genus and species: . Although this tuple looks no different from the at first glance, what it *models* is different because there is a hierarchy behind it. Escherichia is more important than coli. Not only is order important, but the order indicates a hierarchy. > […] > Let's move the holy wars to the REST discussion list where they are > more relevant, ok? Yes, they would be more relevant there. PS: I made an error in a previous post, where I quoted RFC 3986. | The URI syntax is organized hierarchically, with components listed | in order of decreasing significance from left to right. I inserted the commentary ‘with 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. best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgp1metL4KkNv.pgp Description: PGP signature
Re: comments/feedback requested
At Thu, 19 Jul 2007 08:58:41 -0600, Adam Taft <[EMAIL PROTECTED]> wrote: > > > My last message was stupid. Please ignore. :) > > What I was _trying_ to get at was this: > > There Exists a Function which Relates en => de. > > […] >From <http://www.ietf.org/rfc/rfc3986.txt> (URI generic syntax) sec. 1.2.3. | The URI syntax is organized hierarchically [with slashes -egh], with | components listed in order of decreasing significance from left to | right. Which is of greater significance: the language translated from or language translated to? If 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
At Wed, 18 Jul 2007 19:41:09 -0600, Adam Taft <[EMAIL PROTECTED]> wrote: > Really?? That's weird. Wrong even? > > I mean, if you can (or should) use commas, we'd have urls like this: > > /cars,ford,truck,f-series,f150,2007 > > instead of > > /cars/ford/truck/f-series/f150/2007 That is a hierarchy, so it should use slashes. Longitude,latitude is not a hierarchy but a tuple, and they suggest for this commas. > I like the second (with slashes) because it's somewhat a metaphor for > traditional folders on a hard drive. Which is why it'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. slashes: they have different meanings (according to the RWS book). best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpmBw0L7zp6w.pgp Description: PGP signature
Re: 404 from getRepresentation/handleGet?
At Wed, 18 Jul 2007 18:33:29 -0700, "John D. Mitchell" <[EMAIL PROTECTED]> wrote: > (A) Well, to refer to authority... :-) > http://dictionary.reference.com/search?r=2&q=idempotent > http://en.wikipedia.org/wiki/Idempotence_(computer_science) I agree that the definition of idempotence there conflicts with that in RFC 2626. But, with respect, we are not discussing the principle of idempotence as defined on wikipedia, but that in RFC 2616. > (B) I agree that we seem to disagree on what that parenthetical remark > means. I find your interpretation to be wrong w.r.t. what idempotent > means. As you might expect from the thread so far, I take a strict > view on the definition. The RFC isn't helping anything, IMHO, by being > so wishy-washy in its explanation. At this point, since we're > disagreeing about the basics of a pretty straightforward definition, > I'm not sure that there's anything else that I can say that may help. It’s not a parenthetical remark: it is the definition of idempotence in the context of RFC 2616. This is the definition of idempotence in RFC 2616. It has to do with ‘side effects’, and only side effects. I don’t believe this is my own, personal, idiosyncratic interpretation. <http://tech.groups.yahoo.com/group/rest-discuss/message/2628> <http://tech.groups.yahoo.com/group/rest-discuss/message/2612> <http://tech.groups.yahoo.com/group/rest-discuss/message/2629> 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
At Wed, 18 Jul 2007 18:16:43 -0700, "John D. Mitchell" <[EMAIL PROTECTED]> wrote: > FWIW to the intuition, rather than thinking whether or not it's > "hierarchical" it might be worth thinking of it in terms of being > "ordered" (as in order specific). In that case, the ordering of the > pair is critical. You beat me to it! Just to add, the RWS book suggests using commas for ordered pairs in the URI design section, which makes sense to me. | Use punctuation characters to separate multiple pieces of data at | the same level of a hierarchy. 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?
At Wed, 18 Jul 2007 17:48:03 -0700, "John D. Mitchell" <[EMAIL PROTECTED]> wrote: > The RFC is clear in separating out which methods are safe and > idempotent from those that are only idempotent from those that are > neither. Sorry, I was confused. You said: > If it has such side effects then it is, by definition, not > idempotent. I wasn’t sure which side effects you were referring to. I referred to side effects in a functional programming language. I was thinking of server side state changes. Obviously, as you say, some methods have side effects (that is, are not ‘safe’) but are idempotent. To be clear, all safe methods are ipso facto idempotent. Some methods are not safe but nonetheless are declared idempotent. Some are, as you say, neither. > DELETE, for example, "must" be idempotent. Agreed. > PUT is also "must be" idempotent precisely because multiple puts of > the same stuff to the same place gives the same results. Again, to be clear, and I believe this is the crux of our disagreement: 9.1.2. | Methods can also have the property of “idempotence” in that (aside | from error or expiration issues) the side-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?
o long as the state change for the > resource occurred, that's all the client cares about, not whether it's > newly created or not. What is newly created anyway? And, what does > the client care to know the difference? > > The 201 Created status code is only useful when the resource's URL is > not known by the client. Therefore, 201 Created is only applicable to > the POST method, because POST doesn't know what the url is for the > resource in its message body. > > A successful PUT can return 204 No Content for an immediately > successful state change, or 202 Accepted for one that will occur in > the future. There are no other 2xx response codes appropriate for a > PUT operation. Sorry, all these paragraphs are just wrong. From 9.6 (PUT) of RFC 2616: | If a new resource is created, the origin server MUST inform the user | agent via the 201 (Created) response. > Again, this is not arguing HTTP spec, as the HTTP spec is quite a bit > more lenient than the rules I've suggested. And, the rules I've > suggested may not strictly be REST rules, as I believe Fielding was > describing REST as an architectural pattern that is applicable to > protocols other than just HTTP. It is arguing the spec, because (a) you are advocating something that violates the spec, and (b) you were previously laying down as settled law (do not return a 404 from a DELETE) that is not in the spec & and is not clearly defined in Fielding’s thesis and may or may not follow from these principles. True, REST is 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 > PUT => 204, 202 > POST => 201, 202, 205 > DELETE => 204 Look, you can’t argue against a MUST in an RFC. Either you come up with HTTP-next generation, or you follow the spec. > HTML is an abomination to the HTTP spec. So, I'm not arguing what is > in current use, more what it ideally should be. Huh? > No more replies from me. I feel I've hijacked the thread, and we're > obviously way off RESTlet discussion. ;) True, I didn’t mean to start all that. best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpgjOqYPgozX.pgp Description: PGP signature
Re: 404 from getRepresentation/handleGet?
Hi Adam, At Wed, 18 Jul 2007 11:11:54 -0600, Adam Taft <[EMAIL PROTECTED]> wrote: > Right, but see, your resource changed from the first PUT request. > Therefore the Precondition Failed status code is appropriate. Again, > if a resource doesn't change, neither can its status code. The two > are linked together. The point is, the state AFTER each request is processed is the same, but the status code is different. You have argued, w.r.t. DELETE, that as long as we have the same resource state after the request is processed, we must have the same response, whatever the previous state of the resource was (that is, either existing or not existing). But this is not in the HTTP spec, it is not a principle of REST, and it has nothing to do with idempotence. > If your resource hadn't changed in the first PUT request, then the > ETag wouldn't have changed, and therefore the second PUT wouldn't > result in a 412. > I'm not arguing the semantics of the spec, nor the strict definition > of "idempotent." You may be right on these technicalities. I'm just > saying what seems logical (at least to me), and that is one > shouldn't return two different status codes for a resource in the > same state. A logical conclusion of this principle would be that PUT should never return a 201 Created, because this depends on what the state of the resource was before the request was received. PUT should always 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 John, thanks for the great insights. I truly appreciated your > messages. best, Erik Hetzner;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpE5A6wP70j7.pgp Description: PGP signature
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). > > What we're saying is that _because_ the resource is in the same state, > why wouldn't it ALWAYS return the same status code? A counterexample. We have a resource which currently has ETag: "A". A conditional PUT is sent. This PUT has If-Match: "A". The first PUT modifies the resource & returns a 200; our new ETag is "B". We send the first request again; we receive back a 412, precondition failed. PUT has not been made non-idempotent by adding a precondition to it, even though our response is different. Idempotence is a property of the SIDE EFFECTS of a request (ie the changing of state on the server), not the RESPONSE. I think that you are correct in saying that returning a 204 is a good best practice on any DELETE. But this is not a requirement of the spec & it is not a requirement of idempotence as defined by the spec. best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpBkQdLe5p1I.pgp Description: PGP signature
Re: 404 from getRepresentation/handleGet?
At Tue, 17 Jul 2007 17:57:16 -0700, "John D. Mitchell" <[EMAIL PROTECTED]> wrote: > > I read this as 'side effect', like a side effect in functional > > programming. I tend to agree that it would be good if you got then > > same response, but the constraint is that you simply get the same side > > effects, not the same actual response. OPTIONS, for instance, should > > not have side effects, but it has a response. > > If it has such side effects then it is, by definition, not idempotent. Huh? What such side effects? PUT obviously has side effects. Methods without side effects are safe, and by definition idempotent. Methods with side effects might or might not be idempotent. > In practice, some people share the view that it's okay to stretch the > definition to be looser. > > Personally, I've done it both ways since it was convenient to have > some extra information in the response and/or status code. I just > didn't kid myself that the "function" was actually idempotent in those > cases and the only consumers of those resources were programs that, in > essence, I controlled. >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?
At Tue, 17 Jul 2007 17:37:38 -0700, "John D. Mitchell" <[EMAIL PROTECTED]> wrote: > Ah, well, actually, that's the point... Idempotence means you get > the same effect. If the effect is that the resource has been e.g., > deleted successfully then, by definition, you should get the same > status code and response for all of the DELETE calls. I read this as ‘side effect’, like a side effect in functional programming. I tend to agree that it would be good if you got then same response, but the constraint is that you simply get the same side effects, not the same 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 'should never' land, however. It's certainly not something > > that is clearly stated in RFC 2616. > > Actually... Check out section 9.1, particularly 9.1.2 Idempotent Methods. As I understand it, idempotence has to do with side effects, not HTTP responses or their status codes. best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgp0YNtcC3soy.pgp Description: PGP signature
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 you need to know? The fact that the resource is no longer > there satisfies the requirement for DELETE. > > If you MUST know, then follow it up with a GET, which will return a 404. > > Why do this? I had a hard time believing this was good advice until > thinking through this example: > > Two clients request a resource via GET. Then, they both send a DELETE > request at near the same time. The first client gets a 200 OK. The > second gets a 404 Not Found. Why should Not Found be reported to the > second client when his goal was to delete the resource? The goal was > satisfied. > > The goal of the DELETE operation is to change the state of the > resource. That's it. So long as this state change happens (or doesn't > happen), what else is there? There is no error. > > And, it makes the coding super duper easy. You don't have to check > for that mysterious 404 coming out of the server. > > Again, it's analogous to PUT. If two clients PUT a resource and both > of them make the exact same change such that the state of the resource > is what they both expect, is there an error? I say no. > > Make sense? I know this is more of one of those "controversial" REST > issues. But, I've come to know and love it. I hope you do too. ;) You make some really good points; thanks for doing that. I wouldn’t put this in ‘should never’ land, however. It’s certainly not something that is clearly stated in RFC 2616. best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpwO5nZQKR8x.pgp Description: PGP signature
Re: 404 from getRepresentation/handleGet?
At Tue, 17 Jul 2007 14:05:28 -0600, Adam Taft <[EMAIL PROTECTED]> wrote: […] > b) DELETE should NEVER! return a 404. Your server should be happy to > accept DELETE requests to any (logical) resource, whether or not that > resource actually exists or not. […] 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? 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?
At Mon, 16 Jul 2007 20:23:08 +0200, Thierry Boileau <[EMAIL PROTECTED]> wrote: > > Hi Erik > > great! > Actually, release 1.0.2 contains an inner http client planned to be > released with Restlet 1.1. As the development of this client is not > achieved, it has been decided to remove this useless code from release > 1.0.3. Thus, when providing no client extensions, this inner client is > detected when using release 1.0.2 (which leads to some bugs...) and is > not detected with release 1.0.3 which leads to a correct error message > stating that no client 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?
At Mon, 16 Jul 2007 19:39:59 +0200, Thierry Boileau <[EMAIL PROTECTED]> wrote: > > Hello Erik, > > your code seems ok, I just wonder if your classpath is correctly set. > I am able to reproduce your problem (with same post request with > netcat) when my classpath does not contain the httpclient extension > archive. Hi Thierry, Excellent, thank you! I’d thought I was including the extension; but it seems it is a bad idea to upgrade to a new version while trying to solve a problem. In 1.0.3 not including the extension gives you an error, so I think I was using 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?
Hi all,
I am having trouble sending a request to a restlet 1.0.2 service from
another restlet. In brief, using a file representation is not setting
the Content-Length, and if the Content-Length is not set, the Restlet
gives me an empty entity in the request.
Here is some sample code for the client side:
import org.restlet.*;
import org.restlet.data.*;
import org.restlet.resource.*;
import org.restlet.util.*;
public class Test {
public static void main (String[] args) {
try {
Client client = new Client(Protocol.HTTP);
client.start(); // not sure if this is necessary
Request req = new Request(Method.POST,
"http://localhost:8001/jobs/";,
new FileRepresentation("/tmp/test",
MediaType.APPLICATION_XML, 60));
org.restlet.data.Response resp = client.handle(req);
System.out.println(resp.getStatus().getCode());
System.out.println(resp.getEntity().getText());
} catch (Exception e) {
System.out.println("Exception: " + e);
}
}
}
This is run with all the necessary jars (commons httpclient, restlet
httpclient, etc.) If /tmp/test is an xml file, here is our request, as
captured by netcat:
C: POST /jobs/ HTTP/1.1
C: Host:localhost:8001
C: User-Agent:Noelios-Restlet-Engine/1.0.2
C: Accept:*/*
C: Content-Type:application/xml
C: Connection:close
C:
C:
C: [...]
The request object, as sent to my restlet, has an empty entity. If I
add Content-Length and send it using netcat, it goes through fine.
Ditto for using curl. Additionally, my response in the client has a
status of 1001, and an empty entity, when it should be 400, with an
error message as the entity.
Am I doing something wrong with my setting up of an http client?
best,
Erik Hetzner
;; Erik Hetzner, California Digital Library
;; gnupg key id: 1024D/01DB07E3
pgpTR6oPWi61D.pgp
Description: PGP signature
