A webpage is being hosted by apache2, CentOS 6.2.
It Gets HTML, CSS, JS files ok to the client side. But CSS and JS don't render, What can be hapenning? Since they should run 100% on client side...
Two different third-party email products we have are reacting differently to the presence of a content-id header in the MIME source of an email. This is resulting in an inconsistent user experience that we're trying to resolve.
Here's an example:
--boundary-example
Content-Location: CID:somethingatelse
Content-ID: <foo4atfoo1atbar.net>
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNv
cHlyaWdodCAoQykgMTk5LiBVbmF1dGhvcml6ZWQgZHV
wbGljYXRpb24gcHJvaGliaXRlZC4A etc..
One email product interprets this as an embedded image. The other interprets this as an ordinary attachment (not embedded). If we completely remove the Content-ID line, both products think the attachment is not embedded.
Is there a specific RFC that definitively concludes which behavior is correct? A colleague and I reviewed RFC2392 which in the opening abstract says:
The use of [MIME] within email to convey Web pages and their
associated images requires a URL scheme to permit the HTML to refer
to the images or other data included in the message. The Content-ID
Uniform Resource Locator, "cid:", serves that purpose. […] The "cid" scheme refers to a specific body part of a message; its use is generally limited to references to other body parts in the same message as the referring body part. The "mid" scheme may also refer to a specific body part within a designated message, by including the content-ID's address.
So, while not absolute, we're inclined to believe that since all embedded items need a cid to reference them, and that it is “generally limited to other body parts in the same message,” and that attachments don’t need a cid, it is reasonable behavior for an email product to treat the presence of a cid, as an indicator of “intent to embed”.
Can I get confirmation on this?
As seen elsewhere, docx, xlsx and pttx are ZIPs. When uploading them to my web application, file (via libmagic andpython-magic) detects them as being ZIP.
I store the contents of the file as a blob in the database, but naturally I don't want to trust the user with what kind of file type this is. So I would like to trust file for and automatically generate a filename during download.
I know one can modify /etc/magic but the format (magic(5)) is way too complicated for me. I found a bug report on the issue at Debian bugs but since it's from 2008 it doesn't seem to be fixed any time soon.
I guess my only other alternative is to indeed trust the user (but still store the contents as a blob) and only check the file extension based on the file name. This way I can disallow some extensions and allow others. And when the user re-downloads his file, he can have it in whatever way he uploaded it. But this solution is insecure if the file is shared with others, since you can simply rename the file to allow uploading it.
Any ideas?
Lastly, I found a list of magic numbers for docx etc, but I'm unable to convert these into the magic(5) format.
Is there a way to serve unknown file types in IIS 7?
I only want to do this for a single directory where execution is turned off and everything will be served as a static file.
As it is now, I have to add each file extension that I want to serve as a MIME type. I want to serve everything. How can this be done?
On my Apache server I have stored several docx, xlsx pptx files.
Some client browsers think that theses are regular zip files and change the file extension when downloading. How do I make it not do that anymore.
(Using Ubuntu server)