So is HEAD too obscure to garner any interest?
Sean
John D. Mitchell jdmitchell at gmail.com writes:
On 10/3/07, Sean Landis sean.landis at 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
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
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 -
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.
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.
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 based
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, as
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
Erik Hetzner erik.hetzner at 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
Erik Hetzner erik.hetzner at 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
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
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 my-url
It blocks until timeout and then prints:
curl: (18)
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
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
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-safehttp://java.sun.com/javase/6/docs/api/java/util/TreeMap.html.
The simplest fix would be to
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
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
18 matches
Mail list logo
