Skip to content

fix issue #568 - strict conneg should return 406 if no acceptable varian... #592

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 17, 2012

Conversation

adennie
Copy link

@adennie adennie commented May 18, 2012

...t

Use case:

Client does a conditional GET with an Accept header specifying a media
type not advertised by the target resource (via its @get annotation).

The current state of the resource satisfies the condition.

The server has requested strict content negotation

Current behavior: ServerResource.doConditionalHandle() gets a null Variant
back from getPreferredVariant() and passes this to
doGetInfo(Variant target), which calls doGetInfo(), i.e. the variation
with no params. If any registered converter is able to produce a
representation for a null target Variant (e.g. GwtConverter), then
whichever one of those converters "wins" will produce a representation that
gets returned back to doConditionalHandle. Later in that method, the
following code is executed:

if ((Method.GET.equals(​getMethod()) || Method.HEAD
.equals(getMethod()))
&& resultInfo instanceof Representation) {
result = (Representation) resultInfo;

and since the if() statement is true, it proceeds to return the result, and
the client gets back the converter-generated representation instead of a
406.

The fix: in doConditionalHandle(), change

if (existing) {
if (isNegotiated()) {
resultInfo = doGetInfo(getPreferredVariant(getVariants(Method.GET)));
}
to

if (existing) {
if (isNegotiated()) {
Variant preferredVariant = getPreferredVariant(getVariants(Method.GET));
if (preferredVariant == null
&& getConnegService().isStrict()) {
doError(Status.CLIENT_ERROR_NOT_ACCEPTABLE);
} else {
resultInfo = doGetInfo(preferredVariant);
}

…ble variant

Use case:

Client does a conditional GET with an Accept header specifying a media
type not advertised by the target resource (via its @get annotation).

The current state of the resource satisfies the condition.

The server has requested strict content negotation

Current behavior: ServerResource.doConditionalHandle() gets a null Variant
back from getPreferredVariant() and passes this to
doGetInfo(Variant target), which calls doGetInfo(), i.e. the variation
with no params. If any registered converter is able to produce a
representation for a null target Variant (e.g. GwtConverter), then
whichever one of those converters "wins" will produce a representation that
gets returned back to doConditionalHandle. Later in that method, the
following code is executed:

if ((Method.GET.equals(​getMethod()) || Method.HEAD
                .equals(getMethod()))
                && resultInfo instanceof Representation) {
            result = (Representation) resultInfo;

and since the if() statement is true, it proceeds to return the result, and
the client gets back the converter-generated representation instead of a
406.

The fix: in doConditionalHandle(), change

if (existing) {
    if (isNegotiated()) {
            resultInfo = doGetInfo(getPreferredVariant(getVariants(Method.GET)));
    }
to

if (existing) {
    if (isNegotiated()) {
        Variant preferredVariant = getPreferredVariant(getVariants(Method.GET));
        if (preferredVariant == null
                && getConnegService().isStrict()) {
            doError(Status.CLIENT_ERROR_NOT_ACCEPTABLE);
        } else {
            resultInfo = doGetInfo(preferredVariant);
        }
@ghost ghost assigned thboileau Jul 18, 2012
@adennie
Copy link
Author

adennie commented Aug 14, 2012

Hi guys, any chance of getting this into the next RC?
-Andy

@jlouvel
Copy link
Collaborator

jlouvel commented Aug 16, 2012

Hi Andy, we just need a signed JCA at this point in order to move forward with this pull request (code looks good).

Could you quickly provide it us? http://www.restlet.org/community/contribute

Thx,
Jerome

@adennie
Copy link
Author

adennie commented Aug 16, 2012

Hi Jerome, here's the JPA. Thanks!
-Andy

Jerome Louvel mailto:notifications@github.com
Thursday, August 16, 2012 8:21 AM

Hi Andy, we just need a signed JCA at this point in order to move
forward with this pull request (code looks good).

Could you quickly provide it us?
http://www.restlet.org/community/contribute

Thx,
Jerome


Reply to this email directly or view it on GitHub
#592 (comment).

@jlouvel
Copy link
Collaborator

jlouvel commented Aug 16, 2012

Hi Andy,

Thanks for your prompt reply. However, we haven't received your JCA, maybe the attachment failed. Could you send it to the email address indicated on the document?

Best regards,
Jerome

@adennie
Copy link
Author

adennie commented Aug 16, 2012

Ah, yes, I sent it to the wrong address. I just sent it to the correct
one. Sorry.
-Andy

Jerome Louvel wrote:

Hi Andy,

Thanks for your prompt reply. However, we haven't received your JCA,
maybe the attachment failed. Could you send it to the email address
indicated on the document?

Best regards,
Jerome


Reply to this email directly or view it on GitHub
#592 (comment).

jlouvel pushed a commit that referenced this pull request Aug 17, 2012
fix issue #568 - strict conneg should return 406 if no acceptable varian...
@jlouvel jlouvel merged commit c659d95 into restlet:master Aug 17, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants