Skip to content
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

Use Response instead of BaseResponse #674

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

maximino-dev
Copy link

@maximino-dev maximino-dev commented Mar 30, 2022

In the new werkzeug version released on 2022 - 03 - 28, the BaseResponse class has been removed (because it's deprecated) and replaced by Response. Using the Response class in the core.py file will now probably resolve incompatibility issues.
Fixes #673

arnimarj
arnimarj previously approved these changes Mar 31, 2022
@moy
Copy link

moy commented Apr 5, 2022

You may want to add Fixes #673 somewhere in the commit message so that merging the PR fixes the bug.

With your patch, httpbin would have a strong dependency on werkzeug. I don't know what's httpbin policy on dependencies, but I guess you need to either:

  • Update Pipfile.lock and Pipfile to reflect this new dependency
  • or write conditional code so that httpbin works with both old and new versions (if Response is not found, import BaseResponse and do Response = BaseResponse)

@florimondmanca
Copy link

florimondmanca commented Apr 5, 2022

Agreed, we might want to use something like this:

try:
    from werkzeug.wrappers import Response
except ImportError:  # werkzeug < 2.1
    from werkzeug.wrappers import BaseResponse as Response

@maximino-dev
Copy link
Author

The Response class is written even in the old werzeug versions, but in the version 1.x and older, there's not the autocorrect_location_header which is modified in httpbin, so there will be an error if we write this conditionnal code.
Importing Response in any of the 2.x werkzeug versions will normally work. So I think that the best way is to update the pipfiles.

@hemberger
Copy link

I agree with @maximino-dev that updating the pipfiles to a >=2.0 constraint on werkzeug and exclusively using Response is probably the best progressive solution. However, if the higher priority is to retain compatibility with old versions of werkzeug, then what about this variation of @florimondmanca's suggestion:

try:
    from werkzeug.wrappers import BaseResponse as Response
except ImportError:  # werkzeug >= 2.1
    from werkzeug.wrappers import Response

This will use Response for werkzeug >= 2.1 and will use BaseResponse for < 2.1. In all cases, the class being imported will have the autocorrect_location_header property.

@moy
Copy link

moy commented Apr 6, 2022

FYI, Werkzeug 2.0 was released on May 11th, 2021 (i.e. not "very recent" but not so old either), so it may be nice to support older versions if there's a simple way to do it. No strong opinion here, and I leave it to the httpbin maintainers anyway to decide.

@yan12125
Copy link

However, if the higher priority is to retain compatibility with old versions of werkzeug, then what about this variation of @florimondmanca's suggestion:

As per #649, for werkzeug >= 2.0 (note that the boundary is not 2.1), autocorrect_location_header should be set on Response instead of BaseResponse. As a result, @florimondmanca's approach in #674 (comment) is better.

@maximino-dev
Copy link
Author

maximino-dev commented Apr 12, 2022

So we can maybe try something like this :

try:
        from werkzeug.wrappers import Response
        from werkzeug.wrappers import BaseResponse
except ImportError: # werkzeug >= 2.1.0
        from werkzeug.wrappers import Response

. . .

try:
        Response.autocorrect_location_header = False
except NameError: # werkzeug < 2.0.0
        BaseResponse.autocorrect_location_header = False

It imports Response and BaseResponse for werkzeug < 2.1.0 (otherwise just Response for werkzeug >= 2.1.0) and changes the autocorrect_location_header attribute in Response, or in BaseResponse if werkzeug < 2.0.0.

@hemberger
Copy link

I think @maximino-dev's solution covers all the bases. However, it seems a shame to encode the complicated history of werkzeug into this library. Perhaps we could just add a werkzeug 2.0+ requirement to this PR and call it a day?

@yan12125
Copy link

Perhaps we could just add a werkzeug 2.0+ requirement to this PR and call it a day?

Definitely fine for me! Anyway, that's up to postmanlabs developers. Maybe @MikeRalphson (reviewer of #649) can give some suggestions? Sorry for bothering if you no longer work on this.

archlinux-github pushed a commit to archlinux/svntogit-community that referenced this pull request Apr 15, 2022
Keeping compatibility with older werkzeug can be quite complicated, so I
decided to only consider the latest werkzeug and use the simplest patch.

The patch httpbin-werkzeug-2.0.0.patch is no longer needed, as it fixes
the same issue as httpbin-werkzeug-2.1.0.patch:
`autocorrect_location_header` not set on the correct class.

Fixes https://bugs.archlinux.org/task/74443
See: postmanlabs/httpbin#674

git-svn-id: file:///srv/repos/svn-community/svn@1186428 9fca08f4-af9d-4005-b8df-a31f2cc04f65
archlinux-github pushed a commit to archlinux/svntogit-community that referenced this pull request Apr 15, 2022
Keeping compatibility with older werkzeug can be quite complicated, so I
decided to only consider the latest werkzeug and use the simplest patch.

The patch httpbin-werkzeug-2.0.0.patch is no longer needed, as it fixes
the same issue as httpbin-werkzeug-2.1.0.patch:
`autocorrect_location_header` not set on the correct class.

Fixes https://bugs.archlinux.org/task/74443
See: postmanlabs/httpbin#674


git-svn-id: file:///srv/repos/svn-community/svn@1186428 9fca08f4-af9d-4005-b8df-a31f2cc04f65
@evilham
Copy link

evilham commented Apr 29, 2022

Hey, FWIW this is the open issue on FreeBSD's ports tree: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263650
And this is the patch being applied:

 from werkzeug.datastructures import WWWAuthenticate, MultiDict
 from werkzeug.http import http_date
-from werkzeug.wrappers import BaseResponse
 from werkzeug.http import parse_authorization_header
 from raven.contrib.flask import Sentry
+# https://github.com/postmanlabs/httpbin/pull/674
+try:
+    from werkzeug.wrappers import BaseResponse as Response
+except ImportError: # werkzeug >= 2.1.0
+    from werkzeug.wrappers import Response
 
 from . import filters
 from .helpers import get_headers, status_code, get_dict, get_request_range, check_basic_auth, check_digest_auth, \
@@ -48,7 +52,7 @@ def jsonify(*args, **kwargs):
     return response
 
 # Prevent WSGI from correcting the casing of the Location header
-BaseResponse.autocorrect_location_header = False
+Response.autocorrect_location_header = False
 
 # Find the correct template folder when running from a different location
 tmpl_dir = os.path.join(os.path.dirname(os.path.abspath(__file__)), 'templates')

@AdamWill
Copy link
Contributor

AdamWill commented Sep 14, 2022

All of these versions of the patch ignore something rather important - core.py also does:

from flask import Flask, Response,...

and then later does stuff like return Response('Invalid status code', status=400), which it's clearly expecting to use flask's Response, not werkzeug's Response. We can't import werkzeug's thing as Response, that's a naming collision.

In my version downstream ATM I do this:

from werkzeug.wrappers import Response as WzResponse
...
WzResponse.autocorrect_location_header = False

@hemberger
Copy link

Yes, the import will need to be aliased. @maximino-dev would you be willing to update your PR to address this point? Thanks!

@maximino-dev
Copy link
Author

You're right, I updated it !

@moy
Copy link

moy commented Nov 10, 2022

The PR looks good to me, and takes all comments into account. I'm not familiar enough with the codebase to claim an official "approve" in a review, but I believe the PR can be merged. It's rather important since the tool is actually broken without this PR with the latest werkzeug.

archlinux-github pushed a commit to archlinux/svntogit-community that referenced this pull request Nov 16, 2022
To fix the issue mentioned at
postmanlabs/httpbin#674 (comment)

git-svn-id: file:///srv/repos/svn-community/svn@1349198 9fca08f4-af9d-4005-b8df-a31f2cc04f65
archlinux-github pushed a commit to archlinux/svntogit-community that referenced this pull request Nov 16, 2022
To fix the issue mentioned at
postmanlabs/httpbin#674 (comment)


git-svn-id: file:///srv/repos/svn-community/svn@1349198 9fca08f4-af9d-4005-b8df-a31f2cc04f65
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.

Incompatibility with werkzeuf 2.1.x (released on 2022-03-28)
9 participants