date:20080529

Ok it seems to work now: The problem was I didn't realize that the 
org.restlet.jar library (1.1M4) that I had referenced in my project did 
_not_ contain the agent.properties / accept.properties. There are only 
the class files in it and so of course the properties couldn't be loaded 
I guess. So I followed your advice, copied the 2 files into my 
project-classpath and voila! - responses default now to HTML in Firefox2


Thanks again!

Ralf

Thierry Boileau schrieb:

Hello Ralf,

could you tell us what is the content of the "accept" header? Is this 
exactly the one specified in the "accept.properties"?

If not, you will have to provide your own file.
Proceed as follow:
 - in a directory of your convenience, add your own "accept.properties" 
file in the following sub-path: org/restlet/service/accept.properties

 - add in your classpath the directory.

Could you keep us informed?

Best regards,
Thierry Boileau

Yes I already use the extension-Tunnel (its a nice feature by the way) 
and yes, if i explicitly write .htm or .html at the end of the uri it 
works. What I want though is that the user gets html even if he 
doesn't use any extension.
There are many use cases imaginable, where a user will not know about 
extensions and just try an URI (e.g. /SOS/OFFERINGS/WeatherMS)
He should then - per default - get Hypermedia which is human-readable 
and points to other representation/resources.


Anyway right now this is not a very urgent problem for me, its just 
something thats been bugging me and I thought I'd share ;-)


P.S.
I'm using Restlet 1.1M4

Stephan Koops schrieb:

Hi Ralf,

I only see that feature, but do not used it yet. Thierry, could you 
help?


Ralf, you could try the extension tunnel. If you add ".html" to the 
URI it automaticly sets the acept header to "text/html".


best regards
  Stephan

Ralf Bommersbach schrieb:
Ok I set getTunnelService.setUserAgentTunnel(true) in the 
constructor of my Application-subclass but no change, still defaults 
to xml... :-(


Do I have to edit the agent/accept.properties?

My Firefox2 user-agent reads:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; 
rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14


best regards
Ralf

Re: Firefox content-negotiation preferences


Ok will do, I'll keep you informed.

Thanks
Ralf

Thierry Boileau schrieb:

Hello Ralf,

could you tell us what is the content of the "accept" header? Is this 
exactly the one specified in the "accept.properties"?

If not, you will have to provide your own file.
Proceed as follow:
 - in a directory of your convenience, add your own "accept.properties" 
file in the following sub-path: org/restlet/service/accept.properties

 - add in your classpath the directory.

Could you keep us informed?

Best regards,
Thierry Boileau

Yes I already use the extension-Tunnel (its a nice feature by the way) 
and yes, if i explicitly write .htm or .html at the end of the uri it 
works. What I want though is that the user gets html even if he 
doesn't use any extension.
There are many use cases imaginable, where a user will not know about 
extensions and just try an URI (e.g. /SOS/OFFERINGS/WeatherMS)
He should then - per default - get Hypermedia which is human-readable 
and points to other representation/resources.


Anyway right now this is not a very urgent problem for me, its just 
something thats been bugging me and I thought I'd share ;-)


P.S.
I'm using Restlet 1.1M4

Stephan Koops schrieb:

Hi Ralf,

I only see that feature, but do not used it yet. Thierry, could you 
help?


Ralf, you could try the extension tunnel. If you add ".html" to the 
URI it automaticly sets the acept header to "text/html".


best regards
  Stephan

Ralf Bommersbach schrieb:
Ok I set getTunnelService.setUserAgentTunnel(true) in the 
constructor of my Application-subclass but no change, still defaults 
to xml... :-(


Do I have to edit the agent/accept.properties?

My Firefox2 user-agent reads:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; 
rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14


best regards
Ralf

RE: Issue when using a custom StatusService


Hi Loic,

Thanks for the report, this has been fixed in SVN trunk.

Best regards,
Jerome


-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Envoyé : jeudi 29 mai 2008 11:20
À : discuss@restlet.tigris.org
Objet : RE: Issue when using a custom StatusService


Hello,

It works, I know have the exception ... But apparently, it's not the real
exception that I throw but the cause of the thrown exception?
Have you implemented a mechanism that, in case and exception have a cause,
put the cause of the exception in the status and not the exception itself?

Because this is an issue for me as I create specific mechanism for specific
exception type : in case a service return an exception in a Resource, I
throw a subclass of ResourceException containing the service exception as
cause, and in the StatusService I direcltuy receive the Service exception.

Regards,

Loïc 

-Original Message-
From: Thierry Boileau [mailto:[EMAIL PROTECTED] 
Sent: 27 May 2008 16:21
To: discuss@restlet.tigris.org
Subject: Re: Issue when using a custom StatusService

Hi Loïc,

You can get the latest built snapshot at this URL: 
"http://www.restlet.org/downloads/";.
it is labelled "Development version (unstable)" and is available as a ZIP
file or as a windows setup file.

The fix consist in letting you recover the exception from the status object
in the getRepresentation method. I hope it fixes your problem.

best regards,
Thierry Boileau

> Thanks Thierry,
>  
> Is their a new release forseen soon or need I to build the jars from 
> the repository?
> In all case, I want to say "Bravo" for this quick bugfixe.
>  
> Regards,
>  
> Loïc
>
> --
> --
> *From:* Thierry Boileau [mailto:[EMAIL PROTECTED]
> *Sent:* 27 May 2008 13:04
> *To:* discuss@restlet.tigris.org
> *Subject:* Re: Issue when using a custom StatusService
>
> Hello Loïc,
>
> thans for your report. This bug is now fixed in the svn repository.
>
> best regards,
> Thierry Boileau
>
>
>> Anybody have aleady had the same issue?
>>
>> -
>> ---
>> *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>> *Sent:* 22 May 2008 13:52
>> *To:* discuss@restlet.tigris.org
>> *Subject:* Issue when using a custom StatusService
>>
>> Hello,
>>
>> I create a StatusService as explained in the tutorial with the 
>> details I gather from the mailing list archives.
>>
>> My getRepresentation() method is called, but when I try to recover 
>> the throwable that generate the error, I have a null!
>>
>> I also implemented the getStatus method, but it is never called!
>>
>> I'm using Restlet 1.1M4 with Spring and a component direclty ( no 
>> application).
>>
>> Big question is, how I can access the throwable that was throw by the 
>> application and why my getStatus method is not caller by the 
>> ComponentStatusFiler (I check the code and normally this should be).
>>
>> Regards,
>>
>> Loïc
>>
>>  DISCLAIMER 
>> http://www.belgacom.be/maildisclaimer
>>
>>  DISCLAIMER 
>> http://www.belgacom.be/maildisclaimer
>>
>
>  DISCLAIMER 
> http://www.belgacom.be/maildisclaimer
>


 DISCLAIMER 
http://www.belgacom.be/maildisclaimer

RE: Guards and authentication mechanisms


Hi all,

Thanks Bruno for the nice synthesis, that definitely helps moving forward. I
have entered a new RFE to consolidate your comments and other ones from
Stephan:

"Refactor authentication and authorization"
http://restlet.tigris.org/issues/show_bug.cgi?id=505 

Stephan, I agree that this will take some time to properly refactor and take
all aspects into account. I've listed 13 (!) related issues that I added in
the "blocks" field. 

I don't think it would be wise to rush changes into 1.1 so I have set the
milestone to 1.2 M1. 

Let's continue the discussion here and/or via comments to the RFE.

Best regards,
Jerome


-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Envoyé : jeudi 29 mai 2008 10:22
À : discuss@restlet.tigris.org
Objet : Re: Guards and authentication mechanisms

Hi Bruno,

The idea is *very* good. I've also thoughts in this direction, but your 
proposal is more complete than my ideas was.
I've also proposed some month ago to switch the Guard to an abstract 
class which do the HTTP things, and ubclasses for the check of the secrets.
Jerome said, if we changed this, there are other classes that could be 
splitted, and the class number will grow and grow.

If I have time when this should be implemented, I can also work on the 
refactoring. On the one hand it is useful to have this available in 
Restlet 1.1, because the authentication already changed since Restlet 
1.0 (the authentication logic moved to the Engine). On the other hand 
this change needs time, and it should not be implemented too fast. 
Jerome, perhaps we could deprecate the authentication methods in 
org.restlet.util.Engine.

AFIAK it is possible, to allow different auth schemes in onw response. 
If we do a great change here, lets look, if we could integrate it.

@Jerome: Independent of this I like to include the issue 503 
(http://restlet.tigris.org/issues/show_bug.cgi?id=503), for the first 
the access to the username of the connector authentication. The access 
to the rolecheck could be done later.
Jerome, could you assign this issue to me? When can I realise it? 
Changes for issue 504 could be done without much more work.

best regards
   Stephan

Bruno Harbulot schrieb:
> 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:
> * Pass

Re: Firefox content-negotiation preferences

2008-05-29 Thread Thierry Boileau


Hi Stephan Koops,

yes it is, if you repeat the blocks, each one with a distinct acceptOld.
But it could be changed.

best regards,
Thierry Boileau


Hi Thierry,

is it possible to have multiple acceptOld for one browser, e.g. for 
different browser versions?


best regards
  Stephan

Thierry Boileau schrieb:

Hello Ralf,

could you tell us what is the content of the "accept" header? Is this 
exactly the one specified in the "accept.properties"?

If not, you will have to provide your own file.
Proceed as follow:
 - in a directory of your convenience, add your own 
"accept.properties" file in the following sub-path: 
org/restlet/service/accept.properties

 - add in your classpath the directory.

Could you keep us informed?

Best regards,
Thierry Boileau

company developing with REST in North Germany?


Hi,

does anyone of you knows a company, which develops with REST / Restlet / 
JAX-RS (or plan to do) and needs a new employee for this?


best regards
  Stephan

Re: Firefox content-negotiation preferences


Hi Thierry,

is it possible to have multiple acceptOld for one browser, e.g. for 
different browser versions?


best regards
  Stephan

Thierry Boileau schrieb:

Hello Ralf,

could you tell us what is the content of the "accept" header? Is this 
exactly the one specified in the "accept.properties"?

If not, you will have to provide your own file.
Proceed as follow:
 - in a directory of your convenience, add your own 
"accept.properties" file in the following sub-path: 
org/restlet/service/accept.properties

 - add in your classpath the directory.

Could you keep us informed?

Best regards,
Thierry Boileau

Re: Firefox content-negotiation preferences

2008-05-29 Thread Thierry Boileau


Hello Ralf,

could you tell us what is the content of the "accept" header? Is this 
exactly the one specified in the "accept.properties"?

If not, you will have to provide your own file.
Proceed as follow:
 - in a directory of your convenience, add your own "accept.properties" 
file in the following sub-path: org/restlet/service/accept.properties

 - add in your classpath the directory.

Could you keep us informed?

Best regards,
Thierry Boileau

Yes I already use the extension-Tunnel (its a nice feature by the way) 
and yes, if i explicitly write .htm or .html at the end of the uri it 
works. What I want though is that the user gets html even if he 
doesn't use any extension.
There are many use cases imaginable, where a user will not know about 
extensions and just try an URI (e.g. /SOS/OFFERINGS/WeatherMS)
He should then - per default - get Hypermedia which is human-readable 
and points to other representation/resources.


Anyway right now this is not a very urgent problem for me, its just 
something thats been bugging me and I thought I'd share ;-)


P.S.
I'm using Restlet 1.1M4

Stephan Koops schrieb:

Hi Ralf,

I only see that feature, but do not used it yet. Thierry, could you 
help?


Ralf, you could try the extension tunnel. If you add ".html" to the 
URI it automaticly sets the acept header to "text/html".


best regards
  Stephan

Ralf Bommersbach schrieb:
Ok I set getTunnelService.setUserAgentTunnel(true) in the 
constructor of my Application-subclass but no change, still defaults 
to xml... :-(


Do I have to edit the agent/accept.properties?

My Firefox2 user-agent reads:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; 
rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14


best regards
Ralf

Re: Firefox content-negotiation preferences

Yes I already use the extension-Tunnel (its a nice feature by the way) 
and yes, if i explicitly write .htm or .html at the end of the uri it 
works. What I want though is that the user gets html even if he doesn't 
use any extension.
There are many use cases imaginable, where a user will not know about 
extensions and just try an URI (e.g. /SOS/OFFERINGS/WeatherMS)
He should then - per default - get Hypermedia which is human-readable 
and points to other representation/resources.


Anyway right now this is not a very urgent problem for me, its just 
something thats been bugging me and I thought I'd share ;-)


P.S.
I'm using Restlet 1.1M4

Stephan Koops schrieb:

Hi Ralf,

I only see that feature, but do not used it yet. Thierry, could you help?

Ralf, you could try the extension tunnel. If you add ".html" to the URI 
it automaticly sets the acept header to "text/html".


best regards
  Stephan

Ralf Bommersbach schrieb:
Ok I set getTunnelService.setUserAgentTunnel(true) in the constructor 
of my Application-subclass but no change, still defaults to xml... :-(


Do I have to edit the agent/accept.properties?

My Firefox2 user-agent reads:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.14) 
Gecko/20080404 Firefox/2.0.0.14


best regards
Ralf

RE: Possible bug in DateUtils.ImmutableDate


Hi Mike,

I have attached the DateUtils class so you can have a closer look at the
ImmutableDate embedded class.

JUnit tests are very easy to write. Look at the simple example attached.

Best regards,
Jerome


-Message d'origine-
De : news [mailto:[EMAIL PROTECTED] De la part de Mike Brzozowski
Envoye : mercredi 28 mai 2008 20:41
A : discuss@restlet.tigris.org
Objet : 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



DateUtils.java
Description: Binary data


ByteUtilsTestCase.java
Description: Binary data

Re: Firefox content-negotiation preferences


Hi Ralf,

I only see that feature, but do not used it yet. Thierry, could you help?

Ralf, you could try the extension tunnel. If you add ".html" to the URI 
it automaticly sets the acept header to "text/html".


best regards
  Stephan

Ralf Bommersbach schrieb:
Ok I set getTunnelService.setUserAgentTunnel(true) in the constructor 
of my Application-subclass but no change, still defaults to xml... :-(


Do I have to edit the agent/accept.properties?

My Firefox2 user-agent reads:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.14) 
Gecko/20080404 Firefox/2.0.0.14


best regards
Ralf

Re: Firefox content-negotiation preferences

Ok I set getTunnelService.setUserAgentTunnel(true) in the constructor of
my Application-subclass but no change, still defaults to xml... :-(

Do I have to edit the agent/accept.properties?

My Firefox2 user-agent reads:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.14)
Gecko/20080404 Firefox/2.0.0.14

best regards
Ralf

Stephan Koops schrieb:

Hi Ralf,

Thierry implemented a feature for this. Take a look at the
TunnelService.userAgentTunnel. You find the config file to replace the
accept header in org/restlet/service/accept.properties and the config
file for check the name of the browser in
org/restlet/data/agent.properties.

As first try to call TunnelService.setUserAgentTunnel(true) and look, if
it works.

best regards
Stephan

Ralf Bommersbach schrieb:

Hello list,
while I absolutely love Firefox, there's one thing that's disturbing
me for a while now (well since I started developing in a RESTful way)
: The standard behavior of Firefox 2 is to prefer an
XML-Representation over an HTML-Representation. You can easily see
that in the Accept-header of the HTTP-Request:

Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

this means if I have a resource that has an human-readable
HTML-Representation and also an XML-Representation (e.g. for
machine-based parsing of the resource) - that if the url has no
extension that explicitly specifies the mime-type (like .atom, or
.htm) - the user gets the xml-Representation of the Resource. This is
often confusing for the user and clearly not very helpful: The
default choice for a Web-Browser (all other things being equal) should
IMHO be Hypermedia.
This Behavior of Firefox 2 is also incosistent with all other Browser
out there (at least as far as I know), which adds to the confusion...

so,my question is: does anyone know of a (preferrably non-hacky) way
to set HTML as the default first choice across _all_ browser (like, if
no extension is given, always assume html...) ?

P.S. By the way, In Firefox 3, HTML seems to be the default

RE: PUT and entity

Hi Jim,

I have just sent an email to the REST discuss list. Let's see what comes out
of it to decide what to do:
http://thread.gmane.org/gmane.comp.web.services.rest/8046

If no one says it is forbidden, we'll allow it technically in the framework.

Best regards,
Jerome

-Message d'origine-
De : Jim Alateras [mailto:[EMAIL PROTECTED] 
Envoye : jeudi 29 mai 2008 00:04
A : discuss@restlet.tigris.org
Objet : 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

RE: Issue when using a custom StatusService

2008-05-29 Thread loic.mathieu


Hello,

It works, I know have the exception ... But apparently, it's not the real 
exception that I throw but the cause of the thrown exception?
Have you implemented a mechanism that, in case and exception have a cause, put 
the cause of the exception in the status and not the exception itself?

Because this is an issue for me as I create specific mechanism for specific 
exception type : in case a service return an exception in a Resource, I throw a 
subclass of ResourceException containing the service exception as cause, and in 
the StatusService I direcltuy receive the Service exception.

Regards,

Loïc 

-Original Message-
From: Thierry Boileau [mailto:[EMAIL PROTECTED] 
Sent: 27 May 2008 16:21
To: discuss@restlet.tigris.org
Subject: Re: Issue when using a custom StatusService

Hi Loïc,

You can get the latest built snapshot at this URL: 
"http://www.restlet.org/downloads/";.
it is labelled "Development version (unstable)" and is available as a ZIP file 
or as a windows setup file.

The fix consist in letting you recover the exception from the status object in 
the getRepresentation method. I hope it fixes your problem.

best regards,
Thierry Boileau

> Thanks Thierry,
>  
> Is their a new release forseen soon or need I to build the jars from 
> the repository?
> In all case, I want to say "Bravo" for this quick bugfixe.
>  
> Regards,
>  
> Loïc
>
> --
> --
> *From:* Thierry Boileau [mailto:[EMAIL PROTECTED]
> *Sent:* 27 May 2008 13:04
> *To:* discuss@restlet.tigris.org
> *Subject:* Re: Issue when using a custom StatusService
>
> Hello Loïc,
>
> thans for your report. This bug is now fixed in the svn repository.
>
> best regards,
> Thierry Boileau
>
>
>> Anybody have aleady had the same issue?
>>
>> -
>> ---
>> *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>> *Sent:* 22 May 2008 13:52
>> *To:* discuss@restlet.tigris.org
>> *Subject:* Issue when using a custom StatusService
>>
>> Hello,
>>
>> I create a StatusService as explained in the tutorial with the 
>> details I gather from the mailing list archives.
>>
>> My getRepresentation() method is called, but when I try to recover 
>> the throwable that generate the error, I have a null!
>>
>> I also implemented the getStatus method, but it is never called!
>>
>> I'm using Restlet 1.1M4 with Spring and a component direclty ( no 
>> application).
>>
>> Big question is, how I can access the throwable that was throw by the 
>> application and why my getStatus method is not caller by the 
>> ComponentStatusFiler (I check the code and normally this should be).
>>
>> Regards,
>>
>> Loïc
>>
>>  DISCLAIMER 
>> http://www.belgacom.be/maildisclaimer
>>
>>  DISCLAIMER 
>> http://www.belgacom.be/maildisclaimer
>>
>
>  DISCLAIMER 
> http://www.belgacom.be/maildisclaimer
>


 DISCLAIMER 
http://www.belgacom.be/maildisclaimer

Re: Firefox content-negotiation preferences

Hi Ralf,

As first try to call TunnelService.setUserAgentTunnel(true) and look, if
it works.

best regards
Stephan

Ralf Bommersbach schrieb:

Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

so,my question is: does anyone know of a (preferrably non-hacky) way
to set HTML as the default first choice across _all_ browser (like, if
no extension is given, always assume html...) ?

P.S. By the way, In Firefox 3, HTML seems to be the default

Firefox content-negotiation preferences


Hello list,
while I absolutely love Firefox, there's one thing that's disturbing me 
for a while now (well since I started developing in a RESTful way) : The 
standard behavior of Firefox 2 is  to prefer an XML-Representation over 
an HTML-Representation. You can easily see that in the Accept-header of 
the HTTP-Request:


Accept: 
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5



this means if I have a resource that has an human-readable 
HTML-Representation and also an XML-Representation (e.g. for 
machine-based parsing of the resource) - that if the url has no 
extension that explicitly specifies the mime-type (like .atom, or .htm) 
- the user gets the xml-Representation of the Resource. This is often 
confusing for the user and clearly  not very helpful: The default choice 
for a Web-Browser (all other things being equal) should IMHO be Hypermedia.
This Behavior of Firefox 2 is also incosistent with all other Browser 
out there (at least as far as I know), which adds to the confusion...


so,my question is: does anyone know of a (preferrably non-hacky) way to 
set HTML as the default first choice across _all_ browser (like, if no 
extension is given, always assume html...) ?


P.S. By the way, In Firefox 3, HTML seems to be the default

Re: Guards and authentication mechanisms