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

not forwarding POST parameters when _format is provided as a URL param on _search #411

Closed
jimsteel opened this Issue Jul 25, 2016 · 7 comments

Comments

Projects
None yet
3 participants
@jimsteel

jimsteel commented Jul 25, 2016

When POSTing a request to _search with a _format URL parameter (e.g. base/CodeSystem/_search?_format=application/xml), the parameters included in the POST body are not being provided to our method annotated with @Search

@jimsteel jimsteel changed the title from not forwarding parameters when _format is provided as a URL param on _search to not forwarding POST parameters when _format is provided as a URL param on _search Jul 25, 2016

jamesagnew added a commit that referenced this issue Sep 26, 2016

@jamesagnew

This comment has been minimized.

Show comment
Hide comment
@jamesagnew

jamesagnew Sep 26, 2016

Owner

Hi Jim, I just tried to reproduce this but it seems like it's working to me. Are you able to glance at the test I committed to see if it is missing any nuance from your setup?

Owner

jamesagnew commented Sep 26, 2016

Hi Jim, I just tried to reproduce this but it seems like it's working to me. Are you able to glance at the test I committed to see if it is missing any nuance from your setup?

@jimsteel

This comment has been minimized.

Show comment
Hide comment
@jimsteel

jimsteel Sep 28, 2016

I still don't really understand what the distinction is between the test case (which looks good) and my use case, but I'm seeing, for example,

curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -H "Cache-Control: no-cache" -d 'name=Smith' "http://fhirtest.uhn.ca/baseDstu3/CodeSystem/_search?_format=application/json"

giving a different result to

curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -H "Cache-Control: no-cache" -d 'name=Smith' "http://fhirtest.uhn.ca/baseDstu3/CodeSystem/_search"

jimsteel commented Sep 28, 2016

I still don't really understand what the distinction is between the test case (which looks good) and my use case, but I'm seeing, for example,

curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -H "Cache-Control: no-cache" -d 'name=Smith' "http://fhirtest.uhn.ca/baseDstu3/CodeSystem/_search?_format=application/json"

giving a different result to

curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -H "Cache-Control: no-cache" -d 'name=Smith' "http://fhirtest.uhn.ca/baseDstu3/CodeSystem/_search"

@jamesagnew

This comment has been minimized.

Show comment
Hide comment
@jamesagnew

jamesagnew Sep 29, 2016

Owner

Fascinating. I see what you mean, and I get different results too between those command lines.. but even using those exact commands in a unit test doesn't seem to yield different results.

Are you seeing this issue on other servers than fhirtest.uhn.ca? I'm wondering if maybe the Apache reverse proxy is monkeying with the request.

Owner

jamesagnew commented Sep 29, 2016

Fascinating. I see what you mean, and I get different results too between those command lines.. but even using those exact commands in a unit test doesn't seem to yield different results.

Are you seeing this issue on other servers than fhirtest.uhn.ca? I'm wondering if maybe the Apache reverse proxy is monkeying with the request.

@jimsteel

This comment has been minimized.

Show comment
Hide comment
@jimsteel

jimsteel Sep 29, 2016

Yeah, I'm seeing the same behaviour in our product not behind any proxy. We have a provider with a method annotated with @Search(), and when debugging, the parameter annotated with @OptionalParam(name=CodeSystem.SP_NAME) is either set or not set depending on whether _format is present in the URL of the POST request.

jimsteel commented Sep 29, 2016

Yeah, I'm seeing the same behaviour in our product not behind any proxy. We have a provider with a method annotated with @Search(), and when debugging, the parameter annotated with @OptionalParam(name=CodeSystem.SP_NAME) is either set or not set depending on whether _format is present in the URL of the POST request.

@jamesagnew

This comment has been minimized.

Show comment
Hide comment
@jamesagnew

jamesagnew Oct 6, 2016

Owner

Ahhhh victory. I figured it out.

The RestfulServer does its own parsing of urlencoded data (the request URL and the POST body) because a few servers (Tomcat and Glassfish) parse using ISO-8859/1 instead of UTF-8, so we don't want to rely on their parse logic.

The issue was that some interceptors were "consuming" the request body before the server had a chance to look at it. I have a fix I'll check in as soon as the tests pass...

Owner

jamesagnew commented Oct 6, 2016

Ahhhh victory. I figured it out.

The RestfulServer does its own parsing of urlencoded data (the request URL and the POST body) because a few servers (Tomcat and Glassfish) parse using ISO-8859/1 instead of UTF-8, so we don't want to rely on their parse logic.

The issue was that some interceptors were "consuming" the request body before the server had a chance to look at it. I have a fix I'll check in as soon as the tests pass...

@lawley

This comment has been minimized.

Show comment
Hide comment
@lawley

lawley Oct 6, 2016

Contributor

That's great news, thanks James.

Can you comment further on the ISO-8859/1 issue? Is that tomcat/glassfish picking up the environment default or is it something else?

Contributor

lawley commented Oct 6, 2016

That's great news, thanks James.

Can you comment further on the ISO-8859/1 issue? Is that tomcat/glassfish picking up the environment default or is it something else?

@jamesagnew

This comment has been minimized.

Show comment
Hide comment
@jamesagnew

jamesagnew Oct 6, 2016

Owner

I don't remember all of the details of my investigation at the time.. but IIRC Tomcat and Glassfish (same underlying codebase for the HTTP stack which is why they do it the same) just used 8859-1 hard coded. I remember reproducing that issue on my Mac, where the platform default is UTF-8.

Ahh, just checked and sure enough I remember right: https://tomcat.apache.org/tomcat-6.0-doc/config/http.html (search for 8859-1)

Owner

jamesagnew commented Oct 6, 2016

I don't remember all of the details of my investigation at the time.. but IIRC Tomcat and Glassfish (same underlying codebase for the HTTP stack which is why they do it the same) just used 8859-1 hard coded. I remember reproducing that issue on my Mac, where the platform default is UTF-8.

Ahh, just checked and sure enough I remember right: https://tomcat.apache.org/tomcat-6.0-doc/config/http.html (search for 8859-1)

@jamesagnew jamesagnew closed this in 11d3ae9 Oct 7, 2016

jamesagnew added a commit that referenced this issue Oct 7, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment