| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
|
| |
Renamed as soup_message_is_feature_disabled(). We need this in WebKit to
check if cookies are available in an existing SoupMessage.
|
|
|
|
|
| |
This way disabling the same feature twice doesn't add a new element to
the list.
|
|
|
|
|
|
|
|
|
|
| |
This adds API for web browsers to set extra information to support
same-site cookies.
Note that usage of SoupSession alone does not provide enough
information to reasonably use these at the moment and require
manually setting the information with the extra context a browser
may have.
|
|
|
|
| |
This prevents some unnecessary string copies and a tiny bit of memory.
|
|
|
|
|
|
|
|
|
|
|
| |
Add new API to add WebSocket extensions to SoupSession and SoupServer
and include an implementation of permessage-deflate extension (see RFC
7692). In the client side, supported extensions are added to the session
as sub-features of a new session feature, SoupWebsocketExtensionManager.
In the client side, supported extensions are added/removed directly using
the new SoupServer API. All functions to negotiate the handshake
(client_prepare, client_verify, server_check and server_process) have
now a _with_extensions alternative to handle the extensions.
|
|
|
|
|
|
| |
Remove the GET_PRIVATE macro and add private getters and setters
for all private members that are accessed internally. This cleans
all deprecation warnings generated from using the GET_PRIVATE macro.
|
|
|
|
| |
This is the only warning I see when building libsoup, so let's fix it.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add SOUP_MESSAGE_DO_NOT_USE_AUTH_CACHE new flag to tell the
SoupAuthManager that it shoudn't use cached credentials to authenticate a
particular message, and that credentials shouldn't be cached either
after a successful authentication.
When SOUP_MESSAGE_DO_NOT_USE_AUTH_CACHE flag is present for a message,
we never query the cached credentials on message starting callback, so
that the SoupAuth is not set there. The SoupAuth is now always set on
the message after authenticate, and the Authorization header updated
right before the message is re-queued when SOUP_MESSAGE_DO_NOT_USE_AUTH_CACHE
is used.
This patch also updates soup_message_set_auth() to no longer update the
Authorization header, but just set the SoupAuth handling the case of
setting the same SoupAuth twice.
https://bugzilla.gnome.org/show_bug.cgi?id=774033
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=757146
|
|
|
|
|
|
|
|
|
|
|
| |
It ensures that a new connection will be created for the message if
there aren't any idle connections available and the current number of
connections have reached any of the limits. When a new dedicated
connection is created, it's automatically removed when the message is
unqueued, without switching to idle state to make sure it can't be
reused.
https://bugzilla.gnome.org/show_bug.cgi?id=744720
|
|
|
|
|
|
|
| |
It's similar to the SoupSession::request-started signal, but it's also
emitted for cached resources.
https://bugzilla.gnome.org/show_bug.cgi?id=731153
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=729987
|
|
|
|
|
| |
Added a note that this API is only meaningful in the context
of a SoupSession (i.e. it's not meaningful for a SoupServer).
|
| |
|
|
|
|
|
|
|
| |
Make it easier to use the request and response bodies from
introspection by providing accessors to get them as GBytes.
https://bugzilla.gnome.org/show_bug.cgi?id=704105
|
|
|
|
|
|
|
| |
g_warn_if_fail() if the Content-Type is invalid, and impove the
annotations.
https://bugzilla.gnome.org/show_bug.cgi?id=686766
|
|
|
|
|
|
|
|
|
|
| |
Rename SoupKnownStatusCode to SoupStatus (so that the type name
matches the enum values), and then, for backward-compatibility, add a
new SoupKnownStatusCode enum with equivalent values so that
introspection-using code that was doing "SoupKnownStatusCode.OK", etc,
will still work.
https://bugzilla.gnome.org/show_bug.cgi?id=684409
|
| |
|
|
|
|
|
|
|
| |
g_cclosure_marshal_generic() is the default signal handler starting
from glib 2.29.12. libsoup already requires glib 2.33.1.
https://bugzilla.gnome.org/show_bug.cgi?id=686042
|
|
|
|
|
|
|
|
| |
Clients can specify a priority for each message added to the SoupSession,
which will determine the order in which it is processed by the
session's message processing queue.
https://bugzilla.gnome.org/show_bug.cgi?id=696277
|
|
|
|
|
|
| |
Remove some includes that I had commented out to see if they were
still needed, but then forgot to actually remove when it turned out
they weren't.
|
|
|
|
|
|
|
|
|
| |
SoupMessage:tls-certificate and SoupMessage:tls-errors were only
getting set for successful https connections. It is useful to have
them be set on failed ones as well. Fix that, and make ssl-test test
it.
https://bugzilla.gnome.org/show_bug.cgi?id=690176
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new SoupConnectionAuth class to help with connection tracking,
and make SoupAuthNTLM a subclass of it. Allow a single SoupAuthNTLM to
carry state information about multiple connections.
Make SoupSession store the SoupConnection a SoupMessage is associated
with on the message, and use that from SoupConnectionAuth rather than
tracking sockets by hand like SoupAuthManager had previously done.
Remove the connection tracking in SoupAuthManager, since it is no
longer needed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the auth-managery parts of SoupAuthManagerNTLM down into
SoupAuthManager, and the NTLMy parts into SoupAuthNTLM (in preparation
for supporting other kinds of connection-based auth such as
Negotiate).
The reorganization also makes it possible to use SoupAuthNTLM to
implement a mock version of /usr/bin/ntlm_auth, so we can extend
ntlm-test to test both the built-in-NTLM and external-NTLM codepaths.
Doing this reveals that, AFAICT, the external codepath did not
previously actually work, because it mis-used
G_SPAWN_FILE_AND_ARGV_ZERO and so ended up passing incorrect arguments
to /usr/bin/ntlm_auth.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally (ie, 12 years ago last week) the HTTP message type in soup
was called SoupRequest, and most SoupRequest variables were called
"req". Shortly after, SoupRequest was renamed to SoupMessage, but none
of the existing "req"s were renamed, and in fact, new ones kept
getting added. Eventually, "msg" became the standard name for a
SoupMessage variable, but a handful of "req"s have managed to survive
to this day. With the increasing integration of the modern-day
SoupRequest, this has gone from "inconsistent" to "confusing", so fix
all the remaining stray "SoupMessage *req"s.
|
| |
|
|
|
|
|
|
| |
This was added as a hacky way to avoid extra memcpy()s in certain use
cases by reading data directly into a caller-provided buffer. However,
SoupRequest now provides a vastly simpler way of doing this.
|
|
|
|
|
|
|
|
|
|
|
|
| |
soup_message_add_header_handler() and
soup_message_add_status_handler() used to have the semantics that the
handlers they added wouldn't be called if the message was cancelled by
a preceding signal handler. This feature accidentally got lost in
2.32, but no one appears to have noticed. Fix up the docs to
correspond to the current reality.
Also, fix part of the add_header_handler() docs that *never*
corresponded to reality.
|
| |
|
|
|
|
|
|
| |
When dealing with SoupMessage-related signals in SoupRequest-using
code, it's useful to be able to get the message's associated
SoupRequest.
|
|
|
|
|
|
|
|
|
|
|
| |
Add SOUP_VERSION_X_XX, SOUP_VERSION_MIN_REQUIRED, and
SOUP_VERSION_MAX_ALLOWED, to enable version-based warnings.
Tag all functions with appropriate SOUP_AVAILABLE_IN_ and
SOUP_DEPRECATED_IN_ macros.
Also, fix up some "Since" tags to not refer to unstable releases or
non-.0 point releases.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SoupContentSniffer
soup-message-io uses the content processors registered for each SoupMessage
to properly setup the stack of streams used to read a particular resource
either downloaded from the network or read from a local cached file. Note
that server-side messages do not have content processor support yet.
SoupContentDecoder becomes a content processor and wraps the given base
stream with a list of decoders when required.
SoupContentSniffer becomes a content processor working at the
SOUP_STAGE_BODY_DATA stage.
https://bugzilla.gnome.org/show_bug.cgi?id=682112
|
|
|
|
|
|
|
| |
In particular, this lets the app indicate that it's OK to use an
existing connection when sending a POST.
https://bugzilla.gnome.org/show_bug.cgi?id=681493
|
|
|
|
|
|
|
|
|
|
|
|
| |
Set the message priv->decoders to NULL after free
to fix
(epiphany:14909): GLib-GObject-CRITICAL **: g_object_unref:
assertion `G_IS_OBJECT (object)' failed
in epiphany from soup_message_cleanup_response.
https://bugzilla.gnome.org/show_bug.cgi?id=680055
|
|
|
|
|
|
|
|
| |
Especially, include soup.h rather than individually including a bunch
of other public soup-*.h files.
Remove unnecessary system includes (many are leftovers from code that
has moved down into glib).
|
|
|
|
|
| |
Also, prefix virtual method implementation names with the class name,
to be consistent with other code.
|
| |
|
| |
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=676742
|
|
|
|
|
| |
Test drive Makefile.glib from bug 654395 (excepted distributed with
the tarball rather than using one installed with glib).
|
|
|
|
|
|
| |
Proxy the new GSocketClient::event signal and emit it on SoupMessage,
when relevant, to allow (a) debugging, (b) status messages, (c) request
timing, (d) fiddling with sockets
|
|
|
|
|
|
|
|
|
|
| |
Add a new SOUP_MESSAGE_NEW_CONNECTION flag, and insist on getting a
brand new SoupConnection for any message that has that flag set, or
that uses a non-idempotent method.
Add a test to misc-test for this.
https://bugzilla.gnome.org/show_bug.cgi?id=578990
|
|
|
|
|
|
|
|
|
| |
It was accidentally getting cleared at the wrong time (although the
tls-certificate and tls-errors properties were still correct).
Also add a test for this case.
https://bugzilla.gnome.org/show_bug.cgi?id=665182
|