summaryrefslogtreecommitdiff
path: root/libsoup/soup-message.c
Commit message (Collapse)AuthorAgeFilesLines
* Make more APIs privatePatrick Griffis2020-09-191-0/+14
|
* Remove deprecated SoupChunkAllocator APIsPatrick Griffis2020-09-191-108/+0
|
* Remove deprecated SoupMessageBody APIPatrick Griffis2020-09-191-10/+0
|
* soup-message: make soup_message_disables_feature_by_type() publicCarlos Garcia Campos2020-07-061-1/+14
| | | | | Renamed as soup_message_is_feature_disabled(). We need this in WebKit to check if cookies are available in an existing SoupMessage.
* soup-message: Use a hash set to store disabled featuresCarlos Garcia Campos2020-07-061-14/+26
| | | | | This way disabling the same feature twice doesn't add a new element to the list.
* Expose support for same-site cookiesPatrick Griffis2020-01-211-0/+148
| | | | | | | | | | 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.
* Always use G_PARAM_STATIC_STRINGSNiels De Graef2020-01-131-17/+34
| | | | This prevents some unnecessary string copies and a tiny bit of memory.
* WebSockets: add support for permessage-deflate extensionCarlos Garcia Campos2019-07-311-0/+17
| | | | | | | | | | | 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.
* SoupMessage: seal access to private membersClaudio Saavedra2019-07-101-0/+68
| | | | | | 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.
* message: Avoid use of deprecated g_type_class_add_privateMichael Catanzaro2019-02-251-34/+62
| | | | This is the only warning I see when building libsoup, so let's fix it.
* soup-headers: accept any 3 digit number as message status codeCarlos Garcia Campos2018-01-091-1/+1
| | | | | | | | | | | | 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 API to disable using cached credentials for a particular SoupMessageCarlos Garcia Campos2016-12-031-28/+15
| | | | | | | | | | | | | | | | | | 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
* Include config.h if needed in the files that do not include it yetIgnacio Casal Quinteiro2015-11-041-0/+4
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=757146
* Add SoupMessage flag SOUP_MESSAGE_IGNORE_CONNECTION_LIMITSCarlos Garcia Campos2015-03-021-0/+6
| | | | | | | | | | | 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
* Add SoupMessage::starting signalCarlos Garcia Campos2015-03-021-0/+24
| | | | | | | 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
* Use soup_message_headers_header_contains()Dan Winship2015-03-011-11/+6
|
* Add missing (nullable) annotations, assorted minor introspection fixesEvan Nemerson2014-11-231-3/+3
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=729987
* soup_message_get_https_status(): Improved documentationTristan Van Berkom2014-10-141-0/+3
| | | | | Added a note that this API is only meaningful in the context of a SoupSession (i.e. it's not meaningful for a SoupServer).
* Misc docs updatesDan Winship2013-12-111-4/+2
|
* SoupMessage: add :request-body-data and :response-body-data propertiesDan Winship2013-11-171-0/+57
| | | | | | | 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
* soup-message: minor fixups to soup_message_set_request/response_body()Dan Winship2013-11-171-4/+11
| | | | | | | 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 SoupStatusDan Winship2013-07-131-1/+1
| | | | | | | | | | 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
* Add/fix some annotationsDan Winship2013-06-291-1/+1
|
* use libfffi-based generic marshaller instead of glib-genmarshalOlivier Blin2013-06-081-13/+12
| | | | | | | 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
* soup-message-queue: add a priority system to the message queueSergio Villar Senin2013-04-171-0/+91
| | | | | | | | 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
* soup-message: belated #include cleanupDan Winship2013-01-121-3/+0
| | | | | | 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.
* soup_message_get_https_status: provide info for failed attempts tooDan Winship2013-01-071-4/+6
| | | | | | | | | 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
* soup-auth-manager: split out connection handlingDan Winship2013-01-021-0/+13
| | | | | | | | | | | | 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.
* Reorganize NTLM authentication, fix ntlm_auth supportDan Winship2012-12-291-5/+5
| | | | | | | | | | | | | | | 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.
* docs: Lots of minor fixes and additionsDan Winship2012-12-271-6/+7
|
* Rename all remaining "SoupMessage *req"s to "msg"Dan Winship2012-12-171-20/+20
| | | | | | | | | | | | 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.
* soup-message: update docs to mention SoupRequest where appropriateDan Winship2012-12-171-18/+30
|
* soup-message: deprecate soup_message_set_chunk_allocator()Dan Winship2012-12-171-2/+10
| | | | | | 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: fix up add_header_handler()/add_status_handler() docsDan Winship2012-12-171-23/+7
| | | | | | | | | | | | 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.
* soup-message: remove gtk-docs on internal methodsDan Winship2012-12-171-127/+0
|
* SoupMessage: add soup_message_get_soup_request()Dan Winship2012-12-101-0/+32
| | | | | | When dealing with SoupMessage-related signals in SoupRequest-using code, it's useful to be able to get the message's associated SoupRequest.
* Add per-version deprecation/availability warningsDan Winship2012-11-081-2/+2
| | | | | | | | | | | 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.
* Added SoupContentProcessor support to SoupMessage, SoupContentDecoder & ↵Sergio Villar Senin2012-11-021-4/+0
| | | | | | | | | | | | | | | | | 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
* SoupMessage: Add SOUP_MESSAGE_IDEMPOTENT flagMilan Crha2012-08-191-1/+6
| | | | | | | 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.Alban Browaeys2012-07-161-0/+1
| | | | | | | | | | | | 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
* Clean up includesDan Winship2012-07-131-9/+4
| | | | | | | | 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).
* Reorganize files to need fewer forward declarationsDan Winship2012-07-131-142/+135
| | | | | Also, prefix virtual method implementation names with the class name, to be consistent with other code.
* Use g_clear_object(), g_clear_pointer()Dan Winship2012-07-131-12/+6
|
* Use g_slist_free_full()Dan Winship2012-07-131-8/+2
|
* Fix a few more introspection warningsDan Winship2012-05-251-2/+2
|
* introspection: Fix warningsJasper St. Pierre2012-05-241-3/+3
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=676742
* Use Makefile.glibDan Winship2012-02-081-12/+12
| | | | | Test drive Makefile.glib from bug 654395 (excepted distributed with the tarball rather than using one installed with glib).
* SoupMessage: add network-event signalDan Winship2011-12-221-0/+43
| | | | | | 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
* Force some SoupMessages to use a fresh SoupConnectionDan Winship2011-12-221-0/+4
| | | | | | | | | | 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
* SoupMessage: fix setting of SOUP_MESSAGE_CERTIFICATE_TRUSTED flagDan Winship2011-11-301-2/+3
| | | | | | | | | 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