void

If you're trying to use pyoperalink and you're getting certificate verification errors:

httplib2.SSLHandshakeError: [Errno 1] _ssl.c:507: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

That might be because libhttpd2's root certificate list is too short (I don't know why).

Quick solution: Download this cacert.pem and save as Python\Lib\libhttpd2\cacerts.txt or Python\Lib\site-packages\libhttp2\cacerts.txt. You'll need administrator privileges and make a backup of cacerts.txt beforehand.

Ostensible explanation: Certificates are chained: there's a handful of root certificates which are used to sign site certificates or second-layer certificates and so on. Open auth.opera.com and study the certificate (in Opera you have to click the green placard in the address bar). At the time of writing the topmost certificate in its chain is "DigiCert High Assurance EV CA-1".

Open cacerts.txt. This is the root certificates libhttpd2 understands. Search for "DigiCert" or "Digi": no matches. Thus, libhttpd2 does not trust the "DigiCert High Assurance". It has to be added to this list. "Quick solution" does this by replacing the file with a longer list of trusted certificates extracted from the list at mozilla.org. You can use any other list in compatible format which contains root certificates you need. (You should study the source before copying it because I may be malevolent or mistaken myself).

I've had a problem with my Apache setup where it couldn't serve images with unicode characters in file names:

 <a href="http://www.boku.ru/img/проверка.jpg">http://www.boku.ru/img/проверка.jpg</a> (really missing right now; just an example)

SCP client (WinSCP) clearly showed files were present, other files from the same folder could be accessed but those with cyrillic characters were returning 404.

Using Wireshark, I determined my browser sends urlencoded text (B0%D0…) instead of bare unicode, but that was, apparently, like it should be.

Studying Apache logs, I've found it complain about missing files, re-encoded in \x notation (\xb0\xd0…). For a while I thought this suggested a problem, but in the end it was unrelated and probably correct behavior.

Turns out, WinSCP does not use UTF-8 by default. Instead it sends file names to server in the local PC encoding, Win-1251 in my case. Looking through WinSCP everything seemed alright because it reads filenames back in the same encoding. But from the server point of view (as seen through SSH for example) those were not Russian characters but some Krakozyabry.

In other words, there really was no проверка.jpg.

To recongifure WinSCP, open Site manager, press Edit, Advanced, "UTF-8 encoding for file names: On", then reconnect. You'll have to rename all affected files.

Someone reported that WordPress at boku.ru hasn’t been remembering the name and email which you enter in comments. I vaguely remembered this working before. After some investigation, turns out it was W3 Total Cache plugin which uses comment_cookie_lifetime filter to drop standard WordPress cookie lifetime from half a year to 30 minutes. And since my site runs as GMT, this was eaten by the 4-hour time difference.

W3 Total Cache did that because for cookie-less visitors it serves fast static version of the page (which can not be tailored for each visitor and have their name pre-entered, the way names are handled now). As long as you have posted a comment, you receive a cookie and WordPress serves you slower, dynamic version of the page. So the longer the cookie lifetime is, the longer you’re going to be served dynamic pages (but the longer your settings are going to be preserved).

This setting can be changed at “Performance > Page Cache > Advanced > Comment cookie lifetime”.

If you’ve stumbled upon this post while solving a related problem, here’s some additional pointers:
1. WordPress stores commenter name/email/url in cookies:
comment_author_*
comment_author_email_*
comment_author_url_*

An example of how querying for these values should look like is in /wp-includes/comment-template.php/comments_template()

2. Your comment form is generated either by this, or by customization hook in your theme’s comments.php.

3. To debug cookies, add print_r($_COOKIES); to your theme’s header.php, don’t forget to remove it later. Use Wireshark or your browser’s request sniffer to track what’s being sent.

Everybody who uses Dropbox have probably seen that you can right-click the file and “Copy shared path”, under which it is accessible in the internet.

I thought it would be nice to have similar functionality for BTSync and wrote the following sсript.

Code on pastebin.

Usage: put the code into “Copy links.cmd”, drop the shorcut to it into “C:\Users\[your username]\AppData\Roaming\Microsoft\Windows\SendTo” or wherever Sent To folder is in your versions of Windows.

Now suppose you have a folder C:\Download\images which is BTSync-ed to your server as http://example.org/lib/img. Create a file C:\Download\images\path.txt and write the above web base path to it.

Now select some files, right-click them and press “Send To -> Copy Links”. Web links for all the selected images are copied into your clipboard:

C:\Download\images\test\file.png --> http://example.org/lib/img/test/file.png

The sсript can also be used if you have a web server running at home which presents some of the files on your PC to the outside world, or even if you share some files and want to copy those as “\\mypc\share\path”. Since the sсript looks for the first available path.txt in the parent directories, you can link different folders to different addresses, or even copy and modify the sсript so that the same folder is linked to several base paths (“Copy as web address”, “Copy as local \\share”).