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 > >b

[DAISY] mails on [EMAIL PROTECTED]

Hi all, some explanation: those subscribed to [EMAIL PROTECTED] will have seen a bulk of mails prefixed with [DAISY] passing by recently. These emails communicate ongoing changes to the documentation, we've decided now to direct those to the commit list, this can be changed later if needed.

Thread-safety in Guard

There is a serious thread-safety problem in org.restlet.Guard (Restlet 1.0.5). The secrets field is lazily initialized without proper synchronization and the TreeMap used to initialize it is not thread-safe. The simplest fix would be to

Re: Facelets

Hi Chuck, I've ported Facelets to Restlets (removed the JSF dependencies). You can get it here: http://trac.sarugo.org/xtc Regards, Michael. Chuck Hinson wrote: Has anyone tried to do anything with Facelets in Restlets. Is it even possible? --Chuck

Facelets

Has anyone tried to do anything with Facelets in Restlets. Is it even possible? --Chuck

Re: HEAD not well supported?

In the message "Re: HEAD not well supported?", dated 10/3/07, Adam Taft wrote: Aron Roberts wrote: The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. Would this also imply that the correct HTTP Status code to be returned from a HEAD r

Re: Restful Login/Identifier

Well, by definition since we don't have a "login" process, we also don't have a "logout" process. What I mean is, the UI for the login process should really be more of a function of the user agent, and as such, it is therefore the user agent's responsibility to provide a "logout" function as

Re: HEAD not well supported?

Aron Roberts wrote: The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. Would this also imply that the correct HTTP Status code to be returned from a HEAD request should be 204, corresponding in the Restlet framework to something like

Re: Restful Login/Identifier

On 10/3/07, Michael Terrington <[EMAIL PROTECTED]> wrote: > > Adam Taft wrote: > > The user agent, of course, still prompts the user for credentials when > > it's appropriate to do so. The login process, as the end user perceives > > it, still happens. It's just all about thinking in "stateless"

Re: Restful Login/Identifier

Adam Taft wrote: The user agent, of course, still prompts the user for credentials when it's appropriate to do so. The login process, as the end user perceives it, still happens. It's just all about thinking in "stateless" RESTful terms, which is it seems hard for some (many? most??) web deve

Re: HEAD not well supported?

At 11:37 PM + 10/3/07, Sean Landis wrote: Here's an interesting follow-up. I have a resource that only implements GET and returns "Ok". As the code implies, a HEAD request will do just like GET. When I run: curl --request head It blocks until timeout and then prints: curl: (18) transfer clo

Re: HEAD not well supported?

Erik Hetzner ucop.edu> writes: > > 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 seem

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

Re: HEAD not well supported?

Erik Hetzner ucop.edu> writes: > I don’t understand what the issue is here? Can you not override > handleHead? 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? > W

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 p

Re: Restful Login/Identifier

I know you're teasing, so I won't be long... but just to be clear, when I say "people should get over this concept of logging in", I mean us developers, not the end users. The user agent, of course, still prompts the user for credentials when it's appropriate to do so. The login process, a

Re: Restful Login/Identifier

Heh, good point Adam. I'm definitely going to start telling my clients they just need to get over this whole silly "logging in" thing... ;-) On 10/3/07, Adam Taft <[EMAIL PROTECTED]> wrote: > > > > JC wrote: > > I am trying to develop a Restful login system. > > I have never found a form or url b

Re: Restful Login/Identifier

JC wrote: I am trying to develop a Restful login system. I have never found a form or url based authentication system that felt anywhere near as good (or even as RESTful) as using Basic Authentication over SSL. First of all, I believe people need to get over this concept of "logging in."

Re: HEAD not well supported?

Rob Heittman wrote: The main reason I've used it is to fetch content-length and make any necessary provisions (check storage space, warn user, etc.) on the client side before fetching the representation. In this case you definitely don't want the whole GET response coming at ya. Ya, OK.

Re: HEAD not well supported?

The main reason I've used it is to fetch content-length and make any necessary provisions (check storage space, warn user, etc.) on the client side before fetching the representation. In this case you definitely don't want the whole GET response coming at ya. - Original Message - F

Re: HEAD not well supported?

Sean, I agree that HEAD should be supported. Just for the sake of discussion, however, I personally don't find HEAD all that interesting in comparison with Conditional GETs. I mean, when does the client ever just want to "see" if a resource has changed (or exists) without actually retrieving

Re: HEAD not well supported?

John D. Mitchell gmail.com> writes: > > On 10/3/07, Sean Landis gmail.com> wrote: > > > > So is HEAD too obscure to garner any interest? > > I think it's probably a good default to have allowHead == true and > default to having handleHead() call handleGet() but head should be > fully supportab

Re: HEAD not well supported?

On 10/3/07, Sean Landis <[EMAIL PROTECTED]> wrote: > > So is HEAD too obscure to garner any interest? I think it's probably a good default to have allowHead == true and default to having handleHead() call handleGet() but head should be fully supportable as you say. FWIW, John

Re: HEAD not well supported?

So is HEAD too obscure to garner any interest? Sean