Re: PUT and entity
Rhett, Yes, forgot i asked this question before. IMHO i wouldn't encode the 'put MUST have a non-null entity) policy in the framework. If you do then you should provide for a mechanism to override it (allowNullEntity or something). From my reading of the HTTP spec doesn't specify that a PUT *MUST* have an entity although i agree that in most cases that would be the case. In my particular case the URL includes all the information required to create the resource but i have to stick in a non-null entity body to get this to work with the framework cheers On 27/05/2008, at 12:37 PM, Rhett Sutphin wrote: Hi Jim, On May 26, 2008, at 7:09 PM, Jim Alateras wrote: Any reason why, i nthe restlet framework, a PUT expects to have an entity. When i issue a PUT with an empty entity i get a 400 response. Last time you asked this question ( http://restlet.tigris.org/servlets/ReadMsg?list=discuss&msgNo=5132 ), I pointed you to an earlier discussion ( http://restlet.tigris.org/servlets/ReadMsg?listName=discuss&msgNo=3902 ). The summary is: the HTTP spec is vague, but most implementations expect PUTs to have an entity. For more details, read that second-linked thread. Is there something in particular that was unclear or that you disagreed with? Rhett cheers
Guards and authentication mechanisms
Hi all, Following the discussion on the authentication scheme a few days ago, I've been looking at - "Access to connector authentication" http://restlet.tigris.org/issues/show_bug.cgi?id=503 - "Add notion of realm" http://restlet.tigris.org/issues/show_bug.cgi?id=504 - "Add support for Guards based password files encrypted by htpasswd" http://restlet.tigris.org/issues/show_bug.cgi?id=485 I've also been looking a bit more generally at Guards, and this raised a few questions/observations/suggestions, which I suppose could be part of this discussion. I get the impression that a few things in the Guard API are there for historical reasons (I suppose the first implementation of Guard only supported HTTP BASIC). I'm trying to think of a Guard class that would be sufficiently abstract to model various types of authentication, not only HTTP BASIC/DIGEST, but also SSL client-certificates, SPNEGO Kerberos, Shibboleth and perhaps forms. I'm just not sure that the notions of Realm (i.e. BASIC/DIGEST realms), Secrets (known Map), SecretResolver, DomainURI and Nonce all belong there. What I mean is that perhaps there should be subclasses of Guard per authentication mechanism. In contrast, the solution suggested to issue 485 (htpasswd) is a subclass, and perhaps there should be the notion of a authentication-provider instead. Similarly, I'm not familiar with the OAuth Guard, but I get the impression it doesn't make much use of Realm, Secrets, etc. For example, in Apache Httpd, it's possible to configure mod_auth_basic [1][2] with several authentication providers used in to authenticate the user, for example file (htpasswd) or ldap. There's also a mechanism that In one of the machines I've set up, I've used something where it's possible to fake the SSL client certificate as a username in the file. (It's thus possible to have cert-based authentication and LDAP username/password as a fallback mechanism.) There would need to be at least two categories of password-based providers: the ones from which the secret can be extracted (required for DIGEST) and the others. It's just a vague suggestion, but there could be something like this: * AuthProvider (abstract?) * SslAuthProvider extends AuthProvider (checking the subject DN or perhaps other things) * PasswordAuthProvider extends AuthProvider (of which the secret itself can't be obtained) - checkPassword(String username, char[] password): boolean * ExtractablePasswordAuthProvider extends PasswordAuthProvider (one that can reveal the secret as well) - getPassword(String username): char[] There could be more concrete implementations: * PasswordMapAuthProvider extends ExtractablePasswordAuthProvider (more or less the same as the current secret map). * LdapAuthProvider extends PasswordAuthProvider (which checks the password against an existing LDAP server) * HtpasswdAuthProvider extends PasswordAuthProvider (which checks the password from a file as described in issue 485) * JdbcAuthProvider extends ExtractablePasswordAuthProvider (which would get the password from a database) Then, perhaps a (more) abstract Guard and then classes like these: * HttpBasicGuard extends Guard (constructed or somehow provided with a PasswordAuthProvider, it doesn't actually need to check against a known secret) * HttpDigestGuard extends Guard (constructed or somehow provider with an ExtractablePasswordAuthProvider, since it would need to know the password) These Guards could also take a list of providers rather than a single one, perhaps to have a fallback solution. All this being said, this wouldn't cover the case I was mentioning earlier of SSL-cert falling back to HTTP BASIC/LDAP, so I'd need to think a bit more about this. In addition, perhaps the AuthProviders could be used in relation to the Realms, etc. They could provide a suitable instance of Principal (e.g. LdapPrincipal, KerberosPrincipal, ... when JAAS is used). There's clearly some overlap between this notion of authentication-providers (similar to Apache Httpd) and the notion of realms (as in Tomcat or Jetty). This would clearly require a bit more thoughts, but does the general idea seem sensible? Best wishes, Bruno. [1] http://httpd.apache.org/docs/2.2/mod/mod_auth_basic.html [2] http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html
Re: Possible bug in DateUtils.ImmutableDate
Hi Mike, Could you write a simple unit test illustrating the issue and attach it to a new bug report? I've never written a unit test, but it's probably high time I learned. Do you use JUnit? Yes, the Restlet project uses JUnit best regards Stephan
Re: Possible bug in DateUtils.ImmutableDate
> Regarding the conditional GET support, is there any reason why you don't > rely on the built-in support that we provide for Resource subclasses? I wasn't aware this support was built-in... is there documentation somewhere for this? All I needed was to be able to set the Last Modified header and check for If-Modified-Since. I found how to configure this in the FileClient but not for dynamically generated resources. > For immutable dates, something strange is that we also override after() in > the ImmutableDate and delegate it as well. So everything is processed by the > same delegate Date instance... I believe from tracing into the code that java.util.Date.after() doesn't call any methods on the target Date, it just reaches directly into its instance fields. > Could you write a simple unit test illustrating the issue and attach it to a > new bug report? I've never written a unit test, but it's probably high time I learned. Do you use JUnit? Thanks, Mike
RE: Restlet Version 1.1
Hi Mahi, Here is the latest roadmap: http://www.restlet.org/about/roadmap Best regards, Jerome _ De : Mahi [mailto:[EMAIL PROTECTED] Envoyé : mercredi 28 mai 2008 05:11 À : discuss@restlet.tigris.org Objet : Restlet Version 1.1 I see the v1.1 is in Milestone 4 testing phase. Does anyone know when v1.1 would be stable? Is there a plan doc? Thanks Mahi "You must be the change you wish to see in the world" -- Mahatma Gandhi.
RE: PUT and entity
Hi Matthias, I fully agree with your description. POP3 and SMTP are also stateful protocols. Best regards, Jerome -Message d'origine- De : Matthias Wauer [mailto:[EMAIL PROTECTED] Envoyé : mardi 27 mai 2008 23:17 À : discuss@restlet.tigris.org Objet : RE: PUT and entity Jerome Louvel schrieb: > ... and I can see how to can be extended to FTP and many other ones. Of course the quality of the mapping depends on the type of protocol/scheme, for example whether or not it is stateless. > Just to make that clear, FTP is _not_ a stateless protocol. As Richardson and Ruby have pointed out in their RESTful Web Services book, it is absolutely stateful. However, the specific use case of retrieving files using the ftp:// URI scheme can be considered stateless. I know it's nitpicking, but worth to mention anyway I think. Btw, thanks for the details on 204, good to know. Have a good night, Matthias
RE: Possible bug in DateUtils.ImmutableDate
Hi Mike, Regarding the conditional GET support, is there any reason why you don't rely on the built-in support that we provide for Resource subclasses? For immutable dates, something strange is that we also override after() in the ImmutableDate and delegate it as well. So everything is processed by the same delegate Date instance... Could you write a simple unit test illustrating the issue and attach it to a new bug report? Best regards, Jerome -Message d'origine- De : news [mailto:[EMAIL PROTECTED] De la part de Mike Brzozowski Envoye : mardi 27 mai 2008 21:03 A : discuss@restlet.tigris.org Objet : Possible bug in DateUtils.ImmutableDate Hi, In trying to implement support for HTTP conditional GET I ran across a bizarre bug which seems to be somehow related to the implementation of ImmutableDate. The scene: lastModified is a java.util.Date (also works if it's a java.sql.Timestamp) corresponding to the last modified date for this resource. final Date clientCopy = request.getConditions().getModifiedSince(); // This represents the "If-Modified-Since" header from the client. /* If this condition is true, the server must send a new copy of the resource (HTTP 200) */ // Both of these calls returns inaccurate results, tested in cases where // lastModified is up to 24 minutes after clientCopy if (clientCopy == null || lastModified.after(clientCopy)) { if (clientCopy == null || !clientCopy.before(lastModified)) { // Both of these calls behave as expected. if (clientCopy == null || lastModified.after(new Date(clientCopy.getTime( { if (clientCopy == null || lastModified.getTime() > clientCopy.getTime()) { I'm not really sure what's going on, but manually extracting the epoch timestamp using getTime() (and either comparing the dates as longs or constructing a canonical java.util.Date) fixes the problem. FWIW, java.util.Date.after() uses some sort of bizarre internal structures (fastTime and cdate) to get an epoch time in millis, and doesn't call subclassers' implementations of getTime(). My theory is that ImmutableDates, since they store their real date in a delegate, keep the date of their creation in their internal fields (inherited from java.util.Date). java.util.Date.after() probably reads from this data and not the delegate. A better strategy for ImmutableDate might be to keep the Date data inside the object itself and override all the setXXX functions to throw Exceptions. This maintains functional type inheritance.