You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
UPDATE
Confirmed that this bug is seen when Geocoder is deployed with Tomcat version 7.0.94. I setup a Geocoder node on our test server using Tomcat 7.0.94 as a base and ran some test calls, results:
DETAILS
Currently observable via the geocoderdlv.api.gov.bc.ca and geocodertst.api.gov.bc.ca instances
This has been patched for now by configuring the nested proxy entry with a request transformer plugin which removes the origin header from the request. This results in a correct 200 message.
The underlying issue appears to be a problem with the application returning an incorrect content-type for .json request. These requests are being returned as plain text instead of .json. This result is the same if a GET request is made directly to the tomcat instance bypassing the proxy.
The above calls are successful for other file formats as well (for example https://geocodertst.api.gov.bc.ca/addresses.kml). The issue appears to be with the way Geocoder is handling requests for mime type .json. In Openshift where these instances are deployed they are using a different version of Tomcat than in prod (OCP image is using Tomcat 7.0.94, prod is using 7.0.81), I've reviewed the web.xml for Tomcat 7.0.94 and it has a proper mime-mapping for application/json.
I think the content-type of text/plain is only the content type of the error message coming back with the 403 forbidden response - it has no relation to the expected json content. The real question is why are we getting the 403 forbidden response. I have CORS setup to be wide open. If you don't pass the origin header to the bypassed version does it return a 200 OK?
Calling our dev server it works fine (it's running Tomcat 8.0.36):
curl -I -XGET -H "Origin: https://office.refractions.net" https://ssl.refractions.net/ols/pub/geocoder/addresses.json
HTTP/1.1 200 OK
Date: Thu, 30 May 2019 18:01:27 GMT
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Security-Policy: script-src 'self' https://code.jquery.comhttps://unipear.api.gov.bc.ca 'unsafe-inline' 'unsafe-eval'
Access-Control-Allow-Origin: https://office.refractions.net
Access-Control-Allow-Credentials: true
Content-Type: application/json
Transfer-Encoding: chunked
The text was updated successfully, but these errors were encountered:
I believe that the json error output support in #21 will resolve this problem. However we need a test that can replicate this issue and then confirm that it is resolved.
Before we can do anything with this, we need to confirm it is still a problem. This ticket is over a year old and we are now running java 11 and tomcat 9, among other changes. Are any users still reporting this problem? I cannot replicate it. I still think that if it remains a problem, the improved error handling in #21 is likely the solution, or at least part of it.
@Darv72 commented on Wed May 29 2019
UPDATE
Confirmed that this bug is seen when Geocoder is deployed with Tomcat version 7.0.94. I setup a Geocoder node on our test server using Tomcat 7.0.94 as a base and ran some test calls, results:
curl -I -XGET -H "Origin: https://office.refractions.net" http://localhost:9606/addresses.json
HTTP/1.1 403 Forbidden
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Security-Policy: script-src 'self' https://code.jquery.com https://unipear.api.gov.bc.ca 'unsafe-inline' 'unsafe-eval'
Content-Type: text/plain
Content-Length: 0
Date: Wed, 29 May 2019 22:05:58 GMT
curl -I -XGET -H "Origin: https://office.refractions.net" http://localhost:9606/addresses.geojson
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Security-Policy: script-src 'self' https://code.jquery.com https://unipear.api.gov.bc.ca 'unsafe-inline' 'unsafe-eval'
Content-Type: application/vnd.geo+json;charset=UTF-8
Transfer-Encoding: chunked
Date: Wed, 29 May 2019 22:06:24 GMT
DETAILS
Currently observable via the geocoderdlv.api.gov.bc.ca and geocodertst.api.gov.bc.ca instances
This has been patched for now by configuring the nested proxy entry with a request transformer plugin which removes the origin header from the request. This results in a correct 200 message.
The underlying issue appears to be a problem with the application returning an incorrect content-type for .json request. These requests are being returned as plain text instead of .json. This result is the same if a GET request is made directly to the tomcat instance bypassing the proxy.
Examples:
GET request for .json format
curl -I -XGET -H "Origin: https://office.refractions.net" https://geocodertst.api.gov.bc.ca/addresses.json
HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=UTF-8
Content-Length: 0
Connection: keep-alive
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Security-Policy: script-src 'self' https://code.jquery.com https://unipear.api.gov.bc.ca 'unsafe-inline' 'unsafe-eval'
Date: Wed, 29 May 2019 21:06:22 GMT
X-RateLimit-Limit-minute: 10000
X-RateLimit-Remaining-minute: 9999
X-Kong-Upstream-Latency: 3
X-Kong-Proxy-Latency: 14
Via: kong/1.1.1
Access-Control-Allow-Origin: https://office.refractions.net
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: Origin,Authorization,Access-Control-Allow-Origin,Access-Control-Allow-Methods,apikey
GET request for geojson
curl -I -XGET -H "Origin: https://office.refractions.net" https://geocodertst.api.gov.bc.ca/addresses.geojson
HTTP/1.1 200 OK
Content-Type: application/vnd.geo+json;charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Security-Policy: script-src 'self' https://code.jquery.com https://unipear.api.gov.bc.ca 'unsafe-inline' 'unsafe-eval'
Date: Wed, 29 May 2019 21:07:48 GMT
X-RateLimit-Limit-minute: 10000
X-RateLimit-Remaining-minute: 9999
X-Kong-Upstream-Latency: 6
X-Kong-Proxy-Latency: 5
Via: kong/1.1.1
Access-Control-Allow-Origin: https://office.refractions.net
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: Origin,Authorization,Access-Control-Allow-Origin,Access-Control-Allow-Methods,apikey
GET request for .json bypassing both proxies
curl -I -XGET -H "Origin: https://office.refractions.net" https://blahblahblah.pathfinder.gov.bc.ca/addresses.json
HTTP/1.1 403 Forbidden
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Security-Policy: script-src 'self' https://code.jquery.com https://unipear.api.gov.bc.ca 'unsafe-inline' 'unsafe-eval'
Content-Type: text/plain
Content-Length: 0
Date: Wed, 29 May 2019 21:09:21 GMT
Set-Cookie: e1fd7fc1519d827d2877f661da3a9231=9c7917238536aaa0c536c3b38daed306; path=/; HttpOnly
The above calls are successful for other file formats as well (for example https://geocodertst.api.gov.bc.ca/addresses.kml). The issue appears to be with the way Geocoder is handling requests for mime type .json. In Openshift where these instances are deployed they are using a different version of Tomcat than in prod (OCP image is using Tomcat 7.0.94, prod is using 7.0.81), I've reviewed the web.xml for Tomcat 7.0.94 and it has a proper mime-mapping for application/json.
@cmhodgson commented on Thu May 30 2019
I think the content-type of text/plain is only the content type of the error message coming back with the 403 forbidden response - it has no relation to the expected json content. The real question is why are we getting the 403 forbidden response. I have CORS setup to be wide open. If you don't pass the origin header to the bypassed version does it return a 200 OK?
Calling our dev server it works fine (it's running Tomcat 8.0.36):
curl -I -XGET -H "Origin: https://office.refractions.net" https://ssl.refractions.net/ols/pub/geocoder/addresses.json
HTTP/1.1 200 OK
Date: Thu, 30 May 2019 18:01:27 GMT
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Security-Policy: script-src 'self' https://code.jquery.com https://unipear.api.gov.bc.ca 'unsafe-inline' 'unsafe-eval'
Access-Control-Allow-Origin: https://office.refractions.net
Access-Control-Allow-Credentials: true
Content-Type: application/json
Transfer-Encoding: chunked
The text was updated successfully, but these errors were encountered: