AliceWonderFull

Oh it’s nginx?

The ps.w.org site identifies itself as apache.

I take that back – further reading it would be easy for them to fix this for the end user.

<Location /whatever>
    ModMimeUsePathInfo on
</Location>

ModMimeUsePathInfo apache module lets apache determine and send the mime type.

So www.ads-software.com can fix this for the end user.

For example, if a file’s svn:mime-type property is set to a non-text MIME type (generally, something that doesn’t begin with text/, though there are exceptions), Subversion will assume that the file contains binary—that is, not human-readable—data. One of the benefits that Subversion typically provides is contextual, line-based merging of changes received from the server during an update into your working file. But for files believed to contain binary data, there is no concept of a “line”. So, for those files, Subversion does not attempt to perform contextual merges during updates. Instead, any time you have locally modified a binary working copy file that is also being updated, your file is renamed with a .orig extension, and then Subversion stores a new working copy file that contains the changes received during the update, but not your own local modifications, at the original filename. This behavior is really for the protection of the user against failed attempts at performing contextual merges on files that simply cannot be contextually merged.

Also, if the svn:mime-type property is set, then the Subversion Apache module will use its value to populate the Content-type: HTTP header when responding to GET requests. This gives a crucial clue about how to display a file when perusing your repository with a web browser.

https://svnbook.red-bean.com/en/1.2/svn.advanced.props.html

Okay so they are probably using the svn apache module and changing this would require patching that module so what I would like it to do for the benefit of joe user isn’t likely to happen.

mime type the server sends has nothing to do with the actual file. You can send application/pdf with a WebM if you want. Won’t work in the browser but you can send it.

With SVN when you upload a binary file without specifying the mime type, most clients will choose application/octet-stream when they tell the SVN server what kind of file it is.

SVN treats text different than binary, because with text files it keeps a record of diffs between commits. So the client tells the SVN server an image is application/octet-stream so it does not treat it as a text file.

SVN mime types were never intended as a means of telling a web server what to send, so clients don’t bother with further identification as they just don’t need to. Not for the purpose of mime types within the context of SVN – which simply is revision control.

But www.ads-software.com uses those mime types to determine what mime type to send in the http header from a web server, and that results in the issue that exists.

They are using the mime type that the svn client sends for the file when the plugin author uploads it.

If you don’t specify the mime type when adding non text files to svn, it uses a generic binary mime type that Chrome and FireFox rightfully interpret as a download.

IE apparently does further analysis of the file (either by extension or looking at the beginning) and handles it as an image, IE is famous for compensating for incorrect mime types which has caused issues in the past.

Plugin authors should specify the correct mime type but reality is this will always be a problem as long as they use SVN so in my humble opinion for the benefit of the user, the server should compensate when the plugin author doesn’t.

Not sure why they aren’t letting apache serve it selecting mime type by extension, but they may have a good reason.

It is not an either or.

Feedback – change the code to detect the mime type based upon the file when serving them rather than relying upon what was specified with the svn checkin.

Many of us in our own web apps do that already to solve exactly this type of issue (as well as preventing malicious software intentionally uploaded with the wrong mime type)

https://gist.github.com/kasparsd/3749872

seems to be what I wanted, I think

Yes. You can make just about anything with wordpress.
You may need some custom plugins, but you have full access to php and MySQL and if pre-existing plugins do not exist for what you need, there are a lot of qualified developers who can make what you need.

Another possibility might be to make a jetpack-eu plugin for users where this is an issue that does the following:

A) Checks to see if a session variable / cookie exists where the user has authorized it. If not:

B) Attach a window.confirm to the submit event – if user agrees, save their agreement in session variable / cookie so you don’t have to bug them every time and then submit.

That would satisfy the legal requirements in the least obtrusive manner to the user as they would not need to be asked every time.

Something like ”This blog uses wordpress.com to manage e-mail subscriptions. Is that okay with you?”

It could either be part of jetpack (satisfying me) or an add-on that requires jetpack for countries / webmasters that require it.

If the confirm cookie is set after asking, it *may* even be kosher to use a cookie associated with wordpress.com (but readable by anyone via JS/Ajax w/ cross-domain hackery) so once confirmed it doesn’t end up asking at every unique blog they visit.

Cookie doesn’t even have to have data, just be there.

Just trying to find constructive solutions.

May not be jetpack but may be some kind of a caching plugin.

Whatever it is, that’s not an apache etag.

The etag is clearly not an etag generated by apache.
The etag looks to be generated by jetpack, so jetpack is probably what is serving the image, and responsible for fracking it up.

Here’s your answer:

[alice@localhost ~]$ curl -I https://ps.w.org/jetpack/assets/screenshot-5.png
HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=31536000
Content-Type: image/png
Date: Wed, 10 Dec 2014 13:03:24 GMT
Etag: "640145//jetpack/assets/screenshot-5.png"
Expires: Thu, 10 Dec 2015 13:03:24 GMT
Last-Modified: Sun, 16 Dec 2012 19:59:35 GMT
Server: Apache
Content-Length: 33269

[alice@localhost ~]$ curl -I https://ps.w.org/jetpack/assets/screenshot-6.png
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Type: application/octet-stream
Date: Wed, 10 Dec 2014 13:03:43 GMT
Etag: "640145//jetpack/assets/screenshot-6.png"
Last-Modified: Sun, 16 Dec 2012 19:59:35 GMT
Server: Apache
Content-Length: 361672

The second is being served with the mime type application/octet-stream.

The server is apache, which usually does mime type based upon extension if served directly by apache – so something else within the wordpress install is actually serving the image and is screwing up the mime type on some occassions.

There’s probably a mod_rewrite directive that sends serving of the files to a script and the script is mis-identifying the file type in the second instance.

https://packetpushers.net/obscurity-security-reality/

An article by Russ White discussing obscurity and security.

If your password really is strong you may be okay but there have been exploits, one just last month, where the password was not necessary.