| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Instead of sending the full header as a string in the signal, send
only the type, and a hash table with the parameters, matching the
get/set_content_type() APIs.
|
| | |
|
| | |
|
| |
|
|
|
| |
The content type sniffing spec says that only the last Content-Type
header should be used.
|
| | |
|
| |
|
|
|
|
| |
When we decide that text/plain is really text/plain, or simply return
the same type the server sent, use the header with parameters
included.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
The HTML5 spec allows user agents to further sniff the content if the
normal 'unknown' algorithm isn't able to find a type, before going
with 'application/octet-stream'. This change uses the already existing
sniff_gio code to perform that sniffing, and also fixes the default
behavior of sniffing to be return the type given by the server.
|
| |
|
|
|
| |
This part of the algorithm is basically checking against the type
table just for image types.
|
| |
|
|
|
| |
Basically, any XML type will be trusted as being correctly given by
the server.
|
| |
|
|
|
|
| |
The unknown handling was first written for the text or binary
algorithm, but it is also used stand-alone, when handling empty,
unknown/unknown, or application/unknown content types.
|
| | |
|
| |
|
|
|
|
|
|
| |
This is a very simply written implementation of the HTML5 algorithm
that sniffs content when the server says it is 'text/plain'. It
detects if the content seems to be binary using a simple test table,
and avoids privilege escalation from text/plain to types known to be
scriptable. Tests included.
|
| |
|
|
|
|
| |
This is the initial work required to implement content sniffing in
libsoup. This first commit provides the new SoupContentSniffer
feature, and hooks it into the message IO code.
|
| | |
|
| |
|
|
|
|
| |
The requirement that it imposed--that we "guess" the name of the index
file when fetching a URL that ended with "/"--is more annoying than
the usefulness of being able to test multiple downloads at once.
|
| | |
|
| |
|
|
|
|
| |
Some servers get annoyed if a POST/PUT declares a Content-Type but
contains no body, so make sure to send a 0-length body (which is
different) instead.
|
| |
|
|
|
|
|
| |
Simplifies implementations, allows for non-http proxy resolution, and
allows authentication information to be passed.
http://bugzilla.gnome.org/show_bug.cgi?id=580051
|
| |
|
|
|
|
|
| |
Move CONNECT handling from SoupConnection to SoupSession so it works
more like other requests. Generally clean up and simplify
SoupConnection, and simplify the coordination between SoupSession and
its subclasses.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we went to some effort to resolve the message URI hostname
to an IP address before figuring out proxies/connections, but this
turns out to be wrong for multiple reasons:
1. Some hosts that send all requests via proxy don't even have a
working DNS config.
(http://bugzilla.gnome.org/show_bug.cgi?id=577532)
2. Apparently no one expects hostnames in requests to be matched
against IP addresses in proxy ignore lists anyway.
3. The big web browsers all implement connection limits on a
per-hostname basis, not a per-IP basis, and some web pages take
advantage of this by using multiple aliases for the same host
to get around the connection limit.
Also update tests/proxy-test to verify that the hostname is not
resolved when passing a request to a proxy.
|
| |
|
|
|
|
|
|
| |
Disable TLS 1.0 too, since some sites don't even support that (I'm
looking at you, PayPal). Eventually we'll want to make this be more
clever, and have it first try TLS 1.1 with extensions, and then fall
back to SSL 3.0 if the server gets confused by the new stuff. But that
will take some rewriting.
|
| |
|
|
|
| |
Apple's CalDAV server apparently considers it mandatory.
http://bugzilla.gnome.org/show_bug.cgi?id=583091
|
| |
|
|
| |
Stupid bash. http://bugzilla.gnome.org/show_bug.cgi?id=583911
|
| |
|
|
| |
http://bugzilla.gnome.org/show_bug.cgi?id=583942
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases, we're reasonably sure it's going to fail if we don't
emit authenticate, but forcing callers to deal with both the
pre-sending and post-sending cases in their authenticate handlers
makes writing them tricky. (In particular, calling
soup_message_io_pause() in the pre-sending case won't work, since the
message hasn't actually started yet.) This also solves the problem
that we were previously emitting "authenticate" both before and after
the message was sent in some cases.
Add a regression test for this case (written by Gustavo Noronha, who
figured out the circumstances where the bug was happening), and tweak
the existing regression tests to match the new rules.
http://bugzilla.gnome.org/show_bug.cgi?id=583462
|
| |
|
|
|
|
| |
It broke tests/ssl-test on machines that support %SSL3_RECORD_VERSION.
For now, we will just not use that flag, and instead always disable
TLS 1.1. The gnutls problem has been reported upstream.
|
| |
|
|
|
|
| |
We weren't using the information it generated, so it had no effect
besides slowing things down with additional DNS traffic. Pointed out
by Christophe Gillette on libsoup-list.
|
| | |
|
| |
|
|
|
|
|
| |
Check that gcc supports -Wmissing-include-dirs and -Wundef rather than
using them unconditionally.
http://bugzilla.gnome.org/show_bug.cgi?id=578851
|
| |
|
|
|
|
|
|
|
| |
The change to support LF LF in addition to CRLF CRLF broke this subtly
so that if the first network read returned a packet that ended at a
CR, then the following LF would be mistakenly interpreted as ending
the headers.
http://bugzilla.gnome.org/show_bug.cgi?id=582002
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Try to use the (not-yet-widely-deployed) SSL3_RECORD_VERSION option in
gnutls to make it handshake according to the backward-compatibility
recommendations in the TLS spec. If that fails, fall back to just
disabling TLS1.1. Should hopefully help us to work better with servers
that freak out if you even suggest using TLS1.1.
Fix based on a Pidgin patch from Martin von Gagern.
http://bugzilla.gnome.org/show_bug.cgi?id=581342
|
| | |
|
| |
|
|
| |
http://bugzilla.gnome.org/show_bug.cgi?id=581754
|
| |
|
|
| |
http://bugzilla.gnome.org/show_bug.cgi?id=581860
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
SoupSessionAsync was mistakenly leaving its own "restarted" handler connected
even after "finished" was emitted. misc-test was supposed to catch that, but
it was using SoupSessionSync rather than Async. Changed it to use Async since
Async adds some signal handlers of its own, while Sync does not.
Fixes #380193, reported by Gustavo Noronha
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|