Updated Spanish translation

belated version bump to 2.39.0

soup-cookie-jar: Add SoupCookieJar:is-persistent property

It allows to query whether cookies are stored persisently by the
SoupCookieJar.

https://bugzilla.gnome.org/show_bug.cgi?id=672838

tests: add some more SoupRequester-based tests

Add SoupRequester-based tests to redirect-test and add
SoupSessionSync-based tests to requester-test.

SoupHTTPRequest: O brave new world!

Kill SoupHTTPInputStream, and have SoupHTTPRequest return the
message's body_istream directly (with a little help from SoupSession
and its subclasses). SoupHTTPRequest works synchronously now as well
(though it's still the case that async only works with
SoupSessionAsync and sync only works with SoupSessionSync).

https://bugzilla.gnome.org/show_bug.cgi?id=591739

soup-message-io: move content sniffing out into a wrapper stream

Add a wrapper input stream that handles content sniffing, and use that
from soup-message-io.

soup-message-io: Use GConverterInputStream for content-decoding

Decode Content-Encodings by wrapping a GConverterInputStream around
the SoupBodyInputStream.

Because we want to be able to fall back to passing data through
undecoded in the case that decoding fails, we need to use a GConverter
wrapper (SoupConverterWrapper) that implements that.

The old soup-message-io code was automatically stopping decompression
when it reached the end of the response body, without checking that
the compressed data was actually whole at that point. Fix that.
However, this breaks the previous hack used for the zlib-to-raw
fallback, since the raw data won't have a checksum at the end.
So do that differently now.

soup-message-io: use gio streams rather than SoupSocket

Use the socket's input/output streams for the base I/O, and add new
SoupBodyInputStream and SoupBodyOutputStream that can be created from
them to handle the body of a single message (including handling
chunked encoding/decoding).

Update chunk-test, which was assuming that the chunk_allocator
callback would never be called if the message had a 0-length body;
that's no longer true.

Add SoupFilterInputStream

SoupFilterInputStream is basically a subset of GDataInputStream, plus
non-blocking read_line()/read_until().

Wrap the existing socket istream member with a SoupFilterInputStream,
and use its buffering rather than doing the buffering in SoupSocket.

SoupSessionAsync: fix the GMainContext tracking

Using (non-reffed) GMainContexts as hash keys can mess up when a
context gets freed and then a new one is created at the same location
(in which case the session might think it has an idle_run_queue
queued, but it doesn't really). Reorganize the way this works to avoid
that problem.

add *.gmo to .gitignore

Added Polish translation

Add gettext support

There were already error messages in soup-request.c and
soup-requester.c marked for translation, and we'll be adding more
soon.

2.38.1

soup-request-file: Update the file-URI-parsing code

using g_file_new_from_uri() breaks a few edge cases. Go back to using
g_file_new_from_path(), and do the special win32 logic by hand.

https://bugs.webkit.org/show_bug.cgi?id=82484

soup-session: unpause messages when cancelling them

Otherwise paused messages get leaked when you abort the session.

https://bugzilla.gnome.org/show_bug.cgi?id=673905

soup-session: fix up TLS/SSL property interactions

SoupSession:ssl-use-system-ca-file was broken, in that setting it to
either TRUE or FALSE would enable it. Fix that, and also fix up the
documentation and property notifications around that,
SoupSession:tls-database, and SoupSession:ssl-ca-file. Add a test to
tests/ssl-test to verify things.

https://bugzilla.gnome.org/show_bug.cgi?id=673678

server: keep a ref on the client context while clearing up

We need to keep a ref on the client context struct for the duration of
the cleanup otherwise it will be disposed of before the
SoupSocket::disconnect callback is called, and that will dereference
the old client context pointer.

Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=673468

Signed-off-by: Jonny Lamb <jonnylamb@gnome.org>

Fix some problems with cancelling an async socket connect op

Cancelling a message while it was still connecting could result in an
(erroneous) warning about "disposing socket while still connected", or
an (accurate) warning about passing NULL to
g_tls_connection_handshake_finish(). Fix both of these.

Pointed out on the mailing list by Sven Neumann.

soup-connection.c: do not unref the socket twice while disconnecting

Reentrant calls to soup_socket_disconnect() when disconnecting the socket
lead to double disconnections and double unref of the same SoupSocket.

https://bugzilla.gnome.org/show_bug.cgi?id=672178

2.38.0

gtk-doc fixes

2.37.92

soup-session.c: add soup_session_prefetch_dns

This deprecates soup_session_prepare_for_uri(). It basically does the same,
i.e., it lets the session prepare for a possible upcoming request by doing
DNS resolution. It additionally has cancellation support and adds a callback
to notify the caller when the operation finishes.

https://bugs.webkit.org/show_bug.cgi?id=41630

2.37.91

Use G_GNUC_BEGIN_IGNORE_DEPRECATIONS (where available)

The XMLRPC API uses GValueArray, so ignore deprecation warnings about
that.

connection-test, requester-test: test non-persistent connections

Make sure non-persistent connections are closed by the time we finish
processing the request.

tests: split connection-test out of misc-test

soup-session: don't mark CONNECTING connections IDLE on cancel

When finishing up a queue item, SoupSession was always marking its
connection IDLE, even if it had previously been CONNECTING. This
created a race condition where if lots of pending connections were
cancelled at once, some of them might see connections labelled IDLE
that didn't actually have a SoupSocket (before those connections got
asynchronously cleaned up). Fix this by only marking connections IDLE
if they had previously been IN_USE.

https://bugzilla.gnome.org/show_bug.cgi?id=667245

requester-test: add some more tests

Make sure that chunked encoding and failed auth work correctly

SoupURI: fix fallback handling of soup_uri_set_path(uri, NULL)

In the old code, if you set a URI's path to NULL and then did
soup_uri_to_string(uri, FALSE), you'd get back a path of "/". Fix the
new code to behave the same way (and test it).

https://bugzilla.gnome.org/show_bug.cgi?id=670431

SoupAuthManagerNTLM: fix don't-fallback-to-Basic code

Sessions using NTLM should never fall back to using Basic auth to
access a resource which advertises NTLM auth. But ntlm-test wasn't
actually testing this, and it broke at some point. Fix that, and
add tests to ntlm-test.

SoupRequestFile: fix handling of URIs with query components

At the moment, gio mishandles file: URIs with query components,
so strip them out before passing the URI to gio.

Also remove some useless code from an earlier incarnation of
SoupRequestFile.

Makefile.glib: Fix locale-specific issues

When using Estonian (et_EE) locale, 'a-z' range skips 'tuv...'

https://bugzilla.gnome.org/show_bug.cgi?id=654395

soup-message-io: prevent a possible out-of-bounds memory access

2.37.90

SoupCache: some issues in SoupCache (3/3)

Check that cache control is not blank to prevent some criticals.

https://bugzilla.gnome.org/show_bug.cgi?id=668865

SoupCache: some issues in SoupCache (2/3)

Do not generate conditional requests to revalidate resources if the server
has not provided neither "Last-Modified" nor "ETag" because the conditional
request could not be properly constructed in that case, and thus, we will
end up issuing two requests for the same resource.

https://bugzilla.gnome.org/show_bug.cgi?id=668865

SoupCache: some issues in SoupCache (1/3)

Respect section 13.9 from specs. Resources whose URL has a query and do not
have expiration time provided by the server must not be cached.

https://bugzilla.gnome.org/show_bug.cgi?id=668865

SoupSessionAsync: don't queue idles from dispose()

SoupSession does a soup_session_abort() from dispose(), which had the
effect in SoupSessionAsync of queueing an idle (to check if new
messages could be sent now that old connections had been closed). This
causes problems if the session was disposed from a thread other than
the one that its GMainContext is running in, which is weird, and also
incompatible with some garbage-collected runtimes. So fix that.

https://bugzilla.gnome.org/show_bug.cgi?id=667364

soup-message-server-io: fix processing of IPv6 HTTP/1.0 messages

When receiving an HTTP/1.0 message with no Host header on an IPv6
interface, SoupServer would internally generate an invalid URL and
then return 400 Bad Request. Fix, and add a test for it.

https://bugzilla.gnome.org/show_bug.cgi?id=666399

soup_form_decode_multipart: check that msg really is a non-NULL message

If it wasn't, the next line would segfault anyway.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=669479
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Dan Winship <danw@gnome.org>

soup_form_decode_multipart: allow file_control_name to be NULL as documented

This was documented as allowed, but would have crashed.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=669479
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Dan Winship <danw@gnome.org>

valgrind run...

soup-uri: revert some of the previously-added return-if-fails

Although it has always been documented that a SoupURI must have a
non-NULL path, nothing ever enforced this, and most methods checked
whether it was NULL before looking at it anyway. So lots of existing
code was getting this wrong, and is now breaking because of the
"g_return_if_fail (SOUP_URI_IS_VALID (uri))" checks.

So, change most of those to just g_warn_if_fail() (while adding back
the old return-if-fail !NULL checks), but also fix soup_uri_set_path()
and soup_uri_new_with_base() to handle NULL paths more sanely (after
warning). Also, allow calling the getters on invalid URIs.

Add a new test to uri-testing to make sure that URIs created with
soup_uri_new(NULL) behave as expected at each step of the way...

https://bugzilla.gnome.org/show_bug.cgi?id=667637

soup-uri: fix the scheme parsing to require alpha, not alphanumeric

also remove an ancient comment about running the regression tests,
since it's implied everywhere now.

Makefile.glib: fix for make earlier than 3.82

Use Makefile.glib

Test drive Makefile.glib from bug 654395 (excepted distributed with
the tarball rather than using one installed with glib).

soup_form_decode_multipart: document all (out) parameters as nullable

Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=669479

tests: sniffing: Avoid loop with uninitialised length

[This would only happen if a request was made to an unhandled path,
which this test doesn't do, but it seems reasonable to return an empty
response rather than crashing. -smcv]

Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Dan Winship <danw@gnome.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=669479
Bug-NB: NB#297634

tests: simple-httpd: Don't leak index_path string

Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Dan Winship <danw@gnome.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=669479
Bug-NB: NB#297634

Safeguard against NULL in strcmp

[In both of these cases, the situation being guarded against is:
check_password() is called, but soup_message_headers_get_one() does not find
an "Authorization" header. -smcv]

Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Dan Winship <danw@gnome.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=669479
Bug-NB: NB#297634

form: Check file pointer before dereferencing

[It's not documented as being allowed to be NULL, but later in the
function there's a check, and GLib convention is generally that all
'out' parameters are allowed to be NULL whether it makes sense or not. -smcv]

Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Dan Winship <danw@gnome.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=669479
Bug-NB: NB#297634

2.37.5

soup_uri_new: do not allow invalid URIs to be returned, except via soup_uri_new (NULL)

Also document the possible NULL return.

Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=667637
Bug-NB: NB#294977

SoupURI: add SOUP_URI_IS_VALID() and use it for basic precondition checks

In this patch, field setters don't have precondition checks for the
validity of the URI object itself, only a non-NULL check, to avoid
breaking existing code if it calls soup_uri_new (NULL) and then sets
fields in an unexpected order:

    uri = soup_uri_new (NULL);                    /* uri is invalid */
    soup_uri_set_host (uri, "www.google.com");
    soup_uri_set_query (uri, "q=badgers");
    soup_uri_set_scheme (uri, "http");            /* still invalid... */
    soup_uri_set_path (uri, "/search");           /* finally valid */

Also annotate nullable setter parameters as (allow-none), to justify
why they don't have a precondition check.

Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=667637
Bug-NB: NB#294977

soup_uri_copy_host: always set the path to something non-NULL

Not doing so is considered to be invalid.

Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=667637
Bug-NB: NB#294977

SoupProxyResolver: construct a valid SoupURI

path = NULL is not considered valid.

Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=667637
Bug-NB: NB#294977

Try to make file:// uris work in win32 too

uri-parsing test: add a case that was exercised by a protocol fuzzer

This was suspected to cause a crash via a NULL path; while it seems it
doesn't actually have that problem, it still seems worth testing.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=667637
Bug-NB: NB#294977
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

uri-parsing test: verify that URIs are split correctly

Testing the round-trip (split + reassemble) is necessary, but not
sufficient: a large proportion of SoupURI's API is in terms of the
separate parts, and this was never explicitly tested before.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=667637
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

soup_uri_new: annotate uri_string as nullable

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=667637
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Dan Winship <danw@gnome.org>

SoupServer: reject non-HTTP URIs and URIs with no host

This prevents a critical warning and other misbehaviour in the
simple-httpd test, when using requests like "GET http: HTTP/1.0".

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=667637
Bug-NB: NB#294977
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Dan Winship <danw@gnome.org>

Header parsing test: verify that a full URI can appear after the "GET"

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=667637
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Dan Winship <danw@gnome.org>

soup_uri_uses_default_port: correct documentation

We now know the default for ftp, too.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=667637
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Dan Winship <danw@gnome.org>

SoupURI: give "foo:" a non-NULL path member

SoupURI documents uri->path as being required, and got_headers in
SoupServer assumes that it's non-NULL, but in fact parsing a URI
consisting solely of a scheme ("foo:") would leave path = NULL.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=667637
Bug-NB: NB#294977
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Dan Winship <danw@gnome.org>

requester-test: add some more tests

Make sure that content-sniffing and redirections work

chunk-test: add a check that wrote-body-data gives the right data

(This was already working, but not tested, on master, but it was
broken on a work branch.)

SoupHTTPInputStream: don't burn through GCancellable fds

SoupSession limits the number of outgoing TCP connections, but
SoupRequestHTTP/SoupHTTPInputStream were still using a file descriptor
for the GCancellable of each request that got queued, even before it
was sent. This meant that if the app queued 1000ish requests all at
once (eg, while rendering an HTML page with *lots* of images), we
would run out of file descriptors.

Fix this by just using the GCancellable::cancelled signal rather than
g_cancellable_get_fd().

https://bugzilla.gnome.org/show_bug.cgi?id=668508

SoupSession: Do not actually send a request if it was cancelled before.

soup_session_cancel_message() may have been called in a REQUEST_STARTED
callback, so it is safer to make sure that
soup_connection_send_request() is called only if that is not the case.

https://bugzilla.gnome.org/show_bug.cgi?id=668098

post-release version bump

soup-message-io: make soup_message_io_unpause() obey use-thread-context

2.37.4

Belatedly add regression test for CVE-2011-2524

https://bugzilla.gnome.org/show_bug.cgi?id=667635

soup-request-http: plug leak

The content type of the request is never freed.

https://bugzilla.gnome.org/show_bug.cgi?id=667099

configure.ac: bump glib requirement to 2.31.7 for GSocketClientEvent

SoupMessage: add network-event signal

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

SoupConnection: belatedly fix up unix-only code

The last-minute-check-if-the-socket-has-been-closed-by-the-server code
was written long ago to use soup_socket_get_fd() and g_poll(), and so
was unix-only, but now that SoupSocket is GSocket-based, we can use
g_socket_condition_check() instead.

Force some SoupMessages to use a fresh SoupConnection

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

soup-headers: misc improvements

Return an error if the headers start with '\0', ignore header lines
with zero-length header names, and convert excess CRs to spaces. All
of these could possibly occur in received headers, and were previously
hitting g_return_if_fails().

Add a bunch of test cases to header-tests to test these cases (and
some others that we already handled correctly but weren't testing).

Fix the documentation of @str on soup_headers_parse* to reflect
reality.

Based on a patch from Simon McVittie.
https://bugzilla.gnome.org/show_bug.cgi?id=666316

2.37.3

Clarify the meaning of #SoupSession:ssl-strict

and fix the Since tags on #SoupSession:ssl-use-system-ca-file
and #SoupSession:tlsdb

https://bugzilla.gnome.org/show_bug.cgi?id=666280

SoupContentDecoder: add another hack to the broken server hack

We were fixing up responses that mistakenly claimed "gzip"
Content-Encoding for gzipped files, but not responses that mistakenly
claimed "x-gzip" encoding.

Honor aclocal flags

https://bugzilla.gnome.org/show_bug.cgi?id=641470

bump version to 2.37.2.1 for the request API changes

SoupRequestHTTP: don't complete send() until after sniffing

If the session has a SoupContentSniffer (and it's not disabled for
this message), wait until content-sniffed is emitted before completing
send()/send_async(). Remove the faked content-sniffed emissions from
the cache codepaths, since they should no longer be needed.

https://bugzilla.gnome.org/show_bug.cgi?id=663451

SoupHTTPInputStream: change handling of error responses

Old behavior:

  - If the (initial) response status code is 3xx/401/407, and the
    message is successfully restarted, then just throw away the
    initial response.

  - If the (final) response status code is 2xx, then stream the body.

  - Otherwise, return a GError from soup_http_input_stream_send*(),
    and don't stream the body.

This worked OK for gvfs, which never cared about the bodies of 4xx
responses, but was problematic for WebKitGTK, which ended up needing
three separate (but interwoven) codepaths to handle all the cases.
(And still ended up handling 407 wrong.)

New behavior:

  - If the (initial) response status code is 3xx/401/407, and the
    message is successfully restarted, then just throw away the
    initial response.

  - The body of the (final) response is always streamed to the caller.

  - A GError is only returned on transport errors, not on 4xx/5xx
    responses

(This is an API break, but SoupHTTPInputStream is not API-stable.)

https://bugzilla.gnome.org/show_bug.cgi?id=663451

soup-session: fix some http-aliases/https-aliases problems

and add a test to misc-test

misc-test: fix a bug

misc-test would crash if it ran long enough (due to either stopping in
gdb or just adding enough new tests to the end) because of a bug in the
max_conns_test cleanup code.

Require glib 2.31 and update to new thread APIs

SoupMessage: fix setting of SOUP_MESSAGE_CERTIFICATE_TRUSTED flag

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

2.37.2

Fix distcheck

coding-test.c: refactored and added deflate support.

Refactored the original code. A couple of utility functions perform now all
the checks.

Content compressed with deflate algorithm (with or without zlib headers) is
also supported and checked.

Adding zlib and raw encoded versions of mbox file for the coding-test

SoupContentDecoder: add support for deflate Content-Encoding

Claim that we support both gzip and deflate content encodings. Added support
to handle data compressed with deflate with and without zlib headers.

https://bugzilla.gnome.org/show_bug.cgi?id=661682

SoupAuthManagerNTLM: allow non-ASCII usernames/passwords

Switch to using the Unicode-encoded form of NTLM, so that non-ASCII
usernames/passwords will work.

Also, add a "-n" option to tests/get to make it use NTLM, and make
SoupAuthManagerNTLM allow passwords-in-URLs.

Based on a patch from Joachim Breitner, sponsored by ITOMIG GmbH and
the City of Böblingen.

https://bugzilla.gnome.org/show_bug.cgi?id=576838

SoupAuthBasic: allow (some) non-ASCII usernames/passwords

Convert the (assumed-UTF-8) username and password into ISO-8859-1
before encoding. This is what a few other browsers do.

Based on a patch from Joachim Breitner, sponsored by ITOMIG GmbH and
the City of Böblingen.

https://bugzilla.gnome.org/show_bug.cgi?id=576838

auth-test: add a test for server-closes-connection-during-auth

auth-test: reorganize this a bit to be more like other test programs