BGDIINF_SB-2197: Returns 415 in case of wrong content-type #93
Conversation
In flask no need to path the request object around, but use the flask global request object. Also avoid linting similarities warning. Removed unnecessary `methods=["GET"]` for the checker, that is the default in Flask and it is then consistent with the /height route.
| @patch('app.routes.georaster_utils') | ||
| def test_profile_validation_wrong_content_type(self, mock_georaster_utils): | ||
| prepare_mock(mock_georaster_utils) | ||
| response = self.test_instance.post('/rest/services/profile.json', headers=self.headers) | ||
| self.assert_response(response, expected_status=415) | ||
|
|
There was a problem hiding this comment.
seems like the CI let this go (as before) to a 400, shouldn't we force the Content-Type to something wrong here so that we are sure to hit the right portion of the if...else?
There was a problem hiding this comment.
Strange was working locally, but your right it would be wiser here to be more explicit, I'll change the test.
|
@pakb can we remove the service-alti-python2 codebuild project, apparently we don't need to support python2 anymore and this codebuild project used anyway python 3.7. |
As you are finalizing the migration to docker, that makes total sense yes. Python2 support was there only to accommodate vhost support |
If the request was done with an invalid content-type, then the service returned a 400, "No 'geom' given, cannot create a profile without coordinates". This was kind of misleading, for example when doing a request with curl without specifying the content-type (curl used application/x-www-form-urlencoded) but with valid payload. The issue was that `request.is_json` in flask is set based on the content-type header and not on the payload being a valid json.
ltshb
force-pushed
the
bug-BGDIINF_SB-2197-wrong-content-type
branch
from
08f4fa3 to
4b84eb8
Compare
If the request was done with an invalid content-type, then the service
returned a 400, "No 'geom' given, cannot create a profile without coordinates".
This was kind of misleading, for example when doing a request with curl without
specifying the content-type (curl used application/x-www-form-urlencoded) but
with valid payload.
The issue was that request.is_json in flask is set based on the content-type header
and not on the payload being a valid json.