| Commit message (Collapse) | Author | Age |
|
|
|
| |
YouTube now sends <title> that occurs 38K into the file...
|
|
|
|
|
|
|
| |
Since 9c845be2797e2047547ec247cb037471aeb48bb0 in curl (7.71.0), setting
CURLOPT_NOBODY to 1 sets the request method to HEAD, but setting it back
to 0 does not change the method back to GET. Setting CURLOPT_HTTPGET
both sets the request method and unsets CURLOPT_NOBODY.
|
|
|
|
|
|
|
|
|
| |
This fixes fetching tweets again!
https://github.com/thelounge/thelounge/pull/ 3602
(Intentionally breaking the link so GitHub doesn't add a "referenced
this PR" thing?)
|
| |
|
|
|
|
|
| |
Apparently sometimes it didn't like receiving its own internal storage
to parse again. Understandable.
|
|
|
|
|
| |
IMDB serves a page to our dumb User-Agent whose <title> is past the 8K
boundary but serves something normal to curl(1).
|
| |
|
|
|
|
| |
This reverts commit 279111dda15dd9170e11b9688eb973f2af2e6300.
|
|
|
|
| |
Perhaps this will make it less suspicious to Google. Who knows.
|
| |
|
|
|
|
|
| |
Aborting the request and leaving data around may be causing intermittent
errors. Just discard the rest of the data.
|
| |
|
| |
|
|
|
|
|
|
| |
Because apparently it's fine for servers to respond with
Content-Encoding you didn't ask for, and curl won't decode it if you
didn't ask for it.
|
|
|
|
| |
Some things don't like you if you don't send one.
|
| |
|
| |
|
|
|
|
| |
Oops, didn't see this.
|
| |
|
| |
|
|
|