| Age | Commit message (Collapse) | Author |
|---|
|
The IPv6 support is stored in the config.h header file, instead of being
passed with the -D flag, so it is easier to read from version.cc.
|
|
Implements support for brotli (br) content encoding.
Fixes: https://github.com/dillo-browser/dillo/issues/377
|
|
Following https://datatracker.ietf.org/doc/html/rfc7230#section-5.3.1,
the path must not be empty, even if we have a query:
> If the target URI's path component is empty, the client MUST send "/"
> as the path within the origin-form of request-target.
Notice URIs can have empty paths, this is a restriction of HTTP only.
Fixes: https://github.com/dillo-browser/dillo/issues/302
|
|
When performing a HTTPS request over a HTTP proxy, a direct connection
is made to the remote server, so the GET line will be received as is.
Therefore we shouldn't send the full URL but just the path.
Fixes: https://github.com/dillo-browser/dillo/issues/279
|
|
Reviewed-by: dogma
|
|
|
|
More data will be written in the SSL_Shutdown() of TLS connections,
which causes errors if the file descriptor is closed. In particular,
LibreSSL will trigger an assert.
Fixes: https://github.com/dillo-browser/dillo/issues/51
|
|
|
|
|
|
The handshake stuff should be named handshake. What should you call
initialize/setup plus handshake, then? I don't know, but 'connect'
for now, anyway.
|
|
as mentioned in the previous commit msg
|
|
Johannes reported that mbed TLS didn't like the connect() to be ongoing
still when the tls handshake was started on osx or dragonfly.
For an earlier version of the fix (which failed), it was basically free
to iterate through the IP address list upon connect() failure, so that
was implemented, and now I'm artificially breaking this patch into two
pieces to commit that separately.
|
|
|
|
|
|
|
|
a status message
|
|
A site triggers this with a background image where the style is deleted
upon </div>, and Capi_stop_client() finds that a_Cache_client_get_if_unique()
is false, so nothing aborts the connection. And there's time for this to
happen because we're doing TLS handshake.
I don't know whether all of what triggered this is doing the right thing,
but at least when it comes to capi, we can see that there's the idea of
permitting it (with whether we ever actually want that in practice being
yet another question).
In any case, Http_make_query_str() definitely thinks the web is there.
If we really decided that we wanted connections to continue without webs,
we could stuff 1) what sort of thing are we requesting? 2) is this a
third-party request? into the socket data. Making the query earlier is
probably not advisable because we'd want the cookies available at the
time that we send the query and not the cookies that were available
somewhat earlier.
|
|
|
|
I used 'hg rename' and expected (at least hoped) that 'hg diff' would
do what I would naturally want, but no.
|
|
And separate http from https for safety while we're at it.
We were checking this where we needed to, but it would be easy to
forget about in the future. Not that very much happens when you
try http://example.com:443 or https://example.com:80, but I'm
being careful nevertheless.
|
|
openbsd tripped over this for me
|
|
Normally I really like to make commits in small pieces that all compile
and make sense in isolation, but with this https work, the effort vs the
reward just wasn't going to make sense.
|
|
|
|
|
|
jeremy's valgrind logs have an instance of
==15610== Invalid read of size 4
==15610== at 0x8090B53: Http_socket_reuse (http.c:668)
|
|
I saw this with valgrind, and I think this is one that used to
appear on Jeremy's logs...
|
|
|
|
|
|
|
|
|
|
...because we need more than fds.
|
|
...because I have changes in mind where I need to keep the queue
easy to deal with.
|
|
...now that floats and grows are in the repo and I won't be making
Sebastian's life difficult with a bunch of whitespace changes.
|
|
http://lists.dillo.org/pipermail/dillo-dev/2014-July/010190.html
and no one objected, and it hasn't given me any trouble, so...
|
|
|
|
machines
(I'm still 32-bit here.)
Thanks to Sebastian for pointing them out.
|
|
|
|
|
|
CONNECT is in RFC 7231 now.
|
|
This makes dillo more responsive when you open an internal link on some site
in a new tab/window and dillo is still loading images for the original page.
|
|
|
|
|
|
|
|
|
|
As https://developer.mozilla.org/en-US/docs/HTTP/Content_negotiation
puts it,
"Considering that :
* UTF-8 is now well-supported by all relevant user-agents,
* the presence of the header increases the configuration-based entropy exposed,
* the presence of the header increases the data transmitted for each request
* almost no sites are using the value of this header for choosing content during the negotiation,
browsers started to stop sending this header in each request, starting with Internet Explorer 8, Safari 5, Opera 11 and Firefox 10. In the absence of Accept-Charset:, servers can simply assume that UTF-8 and the most common characters sets are understood by the client"
Chrome still had it, but then took it out in 2013:
http://code.google.com/p/chromium/issues/detail?id=112804
|
|
privacy
|
|
The httpbis people currently word it as:
'Note: Some non-conformant implementations send the "deflate"
compressed data without the zlib wrapper.'
|
|
The whole situation is a manifestation of corporate rule, but
- it seems that the EU has some data protection laws that could make it
worth something in principle there.
- some large corporations have been shamed into claiming that they will do
a tiny bit of something based on the header value.
|
|
|
|
|
