1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
|
What's New in WebOb 1.8
=======================
Feature
~~~~~~~
- :attr:`Request.POST <webob.request.BaseRequest.POST>` now supports any
requests with the appropriate Content-Type. Allowing any HTTP method to
access form encoded content, including DELETE, PUT, and others. See
https://github.com/Pylons/webob/pull/352
Compatibility
~~~~~~~~~~~~~
- WebOb is no longer officially supported on Python 3.3 which was EOL'ed on
2017-09-29.
Please pin to `WebOb~=1.7` which was tested against Python 3.3, and upgrade
your Python version.
Backwards Incompatibilities
~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Many changes have been made to the way WebOb does Accept handling, not just
for the ``Accept`` header itself, but also for ``Accept-Charset``,
``Accept-Encoding`` and ``Accept-Language``. This was a `Google Summer of
Code <https://developers.google.com/open-source/gsoc/>`_ project completed by
Whiteroses (https://github.com/whiteroses). Many thanks to Google for running
GSoC, the Python Software Foundation for organising and a huge thanks to Ira
for completing the work. See https://github.com/Pylons/webob/pull/338 and
https://github.com/Pylons/webob/pull/335.
If you were previously using the ``Accept`` class or the ``MIMEAccept`` class
directly, please take a look at the documentation for
:func:`~webob.acceptparse.create_accept_header`,
:func:`~webob.acceptparse.create_accept_charset_header`,
:func:`~webob.acceptparse.create_accept_encoding_header` and
:func:`~webob.acceptparse.create_accept_language_header`.
These functions will accept a header value and create the appropriate object.
The :ref:`API documentation for Accept* <acceptheader>` provides more
information on the available API.
- When calling a ``@wsgify`` decorated function, the default arguments passed
to ``@wsgify`` are now used when called with the request, and not as a
`start_response`
.. code::
def hello(req, name):
return "Hello, %s!" % name
app = wsgify(hello, args=("Fred",))
req = Request.blank('/')
resp = req.get_response(app) # => "Hello, Fred"
resp2 = app(req) # => "Hello, Fred"
Previously the ``resp2`` line would have failed with a ``TypeError``. With
this change there is no way to override the default arguments with no
arguments. See https://github.com/Pylons/webob/pull/203
- When setting ``app_iter`` on a ``Response`` object the ``content_md5`` header
is no longer cleared. This behaviour is odd and disallows setting the
``content_md5`` and then returning an iterator for chunked content encoded
responses. See https://github.com/Pylons/webob/issues/86
Experimental Features
~~~~~~~~~~~~~~~~~~~~~
These features are experimental and may change at any point in the future. The
main page provides a list of :ref:`experimental-api` supported by WebOb.
- The cookie APIs now have the ability to set the SameSite attribute on a
cookie in both :func:`webob.cookies.make_cookie` and
:class:`webob.cookies.CookieProfile`. See
https://github.com/Pylons/webob/pull/255
Bugfix
~~~~~~
- :attr:`Request.host_url <webob.request.BaseRequest.host_url>`,
:attr:`Request.host_port <webob.request.BaseRequest.host_port>`,
:attr:`Request.domain <webob.request.BaseRequest.domain>` correctly parse
IPv6 Host headers as provided by a browser. See
https://github.com/Pylons/webob/pull/332
- :attr:`Request.authorization <webob.request.BaseRequest.authorization>` would
raise :class:`ValueError` for unusual or malformed header
values. Now it simply returns an empty value. See
https://github.com/Pylons/webob/issues/231
- Allow unnamed fields in form data to be properly transcoded when calling
:func:`request.decode <webob.request.BaseRequest.decode>` with an alternate
encoding. See https://github.com/Pylons/webob/pull/309
- :class:`Response.__init__ <webob.response.Response>` would discard
``app_iter`` when a ``Response`` had no body, this would cause issues when
``app_iter`` was an object that was tied to the life-cycle of a web
application and had to be properly closed. ``app_iter`` is more advanced API
for ``Response`` and thus even if it contains a body and is thus against the
HTTP RFC's, we should let the users shoot themselves in the foot by returning
a body. See https://github.com/Pylons/webob/issues/305
|
