| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
Some opcode are reserved for future implementations of the
WebSocket protocol. If these reserved code are send,
the connection needs to be closed.
Fix Autobahn test cases 4.*.
https://bugzilla.gnome.org/show_bug.cgi?id=792113
|
|
|
|
|
|
|
|
|
| |
Close connection if reserved bits are different than zero.
These bits should always be 000 because libsoup does not
support extentions that need to use these reserved bits.
Fix Autobahn test cases 3.*
https://bugzilla.gnome.org/show_bug.cgi?id=792113
|
|
|
|
|
|
|
|
| |
Close connection with protocol error if the payload of a
control message is bigger than 125 octets.
Fix Authobahn test case 2.5.
https://bugzilla.gnome.org/show_bug.cgi?id=792113
|
|
|
|
|
|
|
|
|
|
|
|
| |
The HTTP RFC says that status code is extensible, but the category must
be known by the client. However, popular websites like linkedin use
invalid status codes such as 999, and all the major browsers handle that
correctly. There are also WPT tests checking status codes greater than
599 in XMLHTTPRequests. So, let's parse the status code, only failing if
it's not a 3 digit number and letting the user handle any other
particular case.
https://bugzilla.gnome.org/show_bug.cgi?id=792124
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When an upgrade is requested through "Connection: Upgrade" (used for
setting up websocket connection for example), there is no need to
request Keep-Alive.
It turns out doing both is confusing some servers based on the h2o
library.
https://bugzilla.gnome.org/show_bug.cgi?id=788723
|
| |
|
|
|
|
|
| |
GObject now issues warnings for implicit casts on these being
called. See https://bugzilla.gnome.org/show_bug.cgi?id=790697.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=791031
|
| |
|
| |
|
|
|
|
|
|
| |
ssl-test.c: In function ‘main’:
ssl-test.c:465:3: warning: ‘server’ may be used uninitialized in this function [-Wmaybe-uninitialized]
soup_test_server_quit_unref (server);
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=788037
|
|
|
|
|
|
|
| |
The world is moving to Python 3 so do our bit by using Python 3 to run the TLD
parser.
https://bugzilla.gnome.org/show_bug.cgi?id=785735
|
| |
|
|
|
|
|
|
|
| |
Use the HIGHENTROPYVA linker option on x64 builds with MSVC 2012 and
later to enhance the security of the built binaries.
Pointed out by Ignacio Casal Quinteiro.
|
|
|
|
| |
Reorganize the documentation to fix the warnings.
|
|
|
|
|
| |
The calls are supposed to print a new line - fix them. Also fix
a white space errors while touching the file.
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=788920
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The documentation mentions that a value of NULL can be used to let
SoupCache use its default, but code currently tries to call
g_file_test() on NULL in that case, which will cause a critical warning
to be generated.
Refactor how the cache dir default value is initialized to avoid that
issue.
https://bugzilla.gnome.org/show_bug.cgi?id=788452
|
|
|
|
|
|
|
|
| |
The G_GNUC_BEGIN_IGNORE_DEPRECATIONS macro, as used in
soup_session_remove_feature_by_type(), should be balanced by
the complementary G_GNUC_END_IGNORE_DEPRECATIONS macro.
https://bugzilla.gnome.org/show_bug.cgi?id=787166
|
|
|
|
|
|
|
|
| |
Fallback to another authentication type if the current failed. More
specifically if the Negotiate failed (kerberos is not properly
configured), then libsoup should fallback to Basic auth (if server
supports it). Currently in such case it is not possible to load the
page at all (in WebKitGTK+).
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=785774
|
| |
|
|
|
|
|
|
|
|
| |
Also fix a bunch of places that were comparing uri->scheme directly
with SOUP_URI_SCHEME_HTTPS instead of using the private function
soup_uri_is_https().
https://bugzilla.gnome.org/show_bug.cgi?id=784786
|
|
|
|
| |
Found by lintian.
|
|
|
|
|
| |
Some servers seem to close the connection if we send a Ping frame without
any payload. Send a static "libsoup" as payload each time.
|
|
|
|
| |
This allows applications to detect a stalled connection.
|
|
|
|
|
|
|
|
|
|
|
| |
The spec says there should be an empty line (\r\n) between the response
headers and the body. However, some servers don't include the empty line
when the response doesn't have a body. This is causing several WebKit
tests to fail, because some of the imported w3c tests do not include
that empty line. Those tests pass in firefox, chromium and safari, so at
least those other browsers allow that.
https://bugzilla.gnome.org/show_bug.cgi?id=780352
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=785042
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=784935
|
|
|
|
|
|
|
|
|
|
| |
This patch is copied from gst-plugins-good, where souphttpsrc tests
recently started failing because GnuTLS no longer accepts the
certificate: https://bugzilla.gnome.org/show_bug.cgi?id=784005
The new certificate features SAN and SHA256 and is accepted by GnuTLS.
https://bugzilla.gnome.org/show_bug.cgi?id=784949
|
|
|
|
|
|
|
| |
Otherwise the default system CA database is not going to be used if
nothing is given on the commandline, and certificate verification fails.
https://bugzilla.gnome.org/show_bug.cgi?id=784259
|
|
|
|
| |
https://bugs.webkit.org/show_bug.cgi?id=173923
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
returns error
Unfortunately, so many programs (curl, Firefox) ignore the return token that is
included in the response, so it is possible that there are servers that send
back broken stuff. Try to behave in the right way (pass the token to
gss_init_sec_context()), show a warning, but don't fail if the server returned
200.
There is an internal Red Hat site that triggers the described situation
and the "Invalid token was supplied: Unknown error" is being printed to
the console.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a 401 message is received, a new token is generated and saved in
the SoupNegotiateConnectionState's respose header. Later when the connection is
closed (as requested by the server), the state is destroyed together with
the response header. When a new request is being created and we are asked for
the connection authorization, the newly created connection state doesn't have it
set. At this point if the connection state is newly created, generate a new token
together with the response header that will be returned as the connection
authorization.
Also modify how the warning from the soup_gss_build_response is printed
to differentiate if there was a failure during soup_gss_client_init or
soup_gss_client_step.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are several problems with the current state. The main problem is
that the SoupMessage can outlive the SoupAuthNegotiate object and if the
SoupMessage signals handlers are active then they could be called with invalid
SoupAuthNegotiate object. To avoid that use the g_signal_connect_data() and
increase the reference on the SoupAuthNegotiate object. Also rework how
we are connecting the 'got_headers' signal handler to the SoupMessage object, so
they are really connected only once, even if the GSS mechanism involves
multiple rounds.
The whole concept of how we are working with the
SoupAuthNegotiateConnectionState is also wrong. When the connection state is
created it's saved to the private structure and then accessed from
there. The problem is that another state for different message could be
created in the mean time and that one would overwrite the currently set (or if
one would be freed then it would erase the one that is currently set). To solve
this expose the SoupConnectionAuth's get_connection_state_for_message() and
call it when we need the connection state object.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Some files that this script will process might have UTF-8 items in
there, which can cause problems on Python 3.x as it is more strict and
careful on unicode issues. Fix this by:
-Doing what we did before on Python 2.x
-Opening the file with encoding='utf-8' on Python 3.x
|