application octet stream php
4 Answers 4
In times like these, the official HTTP specification is always helpful. From RFC 2616 7.2.1 (my emphasis added):
Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type «application/octet-stream».
The cause of your issue is that the server accepting the file upload does not itself know what type of file has been uploaded. Why? Because it relies on the the HTTP message which sent the file to specify a Content-Type header to determine the exact mime-type. The browser has likely not sent a Content-Type header and the server has assumed application/octet-stream as per the official HTTP specification excerpt above. It’s also possible that the client uploading the file opted not to determine the mime type of the file it was uploading and sent the Content-Type: application/octet-stream header itself.
The mime type of the file, if the browser provided this information. An example would be «image/gif». This mime type is however not checked on the PHP side and therefore don’t take its value for granted.
Do I need Content-Type: application/octet-stream for file download?
If this header [Content-Disposition: attachment] is used in a response with the application/octet-stream content-type, the implied suggestion is that the user agent should not display the response, but directly enter a `save response as. ‘ dialog.
Should I have Content-Type: application/octet-stream if I want browsers to download the file?
1 Answer 1
The content-type should be whatever it is known to be, if you know it. application/octet-stream is defined as «arbitrary binary data» in RFC 2046, and there’s a definite overlap here of it being appropriate for entities whose sole intended purpose is to be saved to disk, and from that point on be outside of anything «webby». Or to look at it from another direction; the only thing one can safely do with application/octet-stream is to save it to file and hope someone else knows what it’s for.
You can combine the use of Content-Disposition with other content-types, such as image/png or even text/html to indicate you want saving rather than display. It used to be the case that some browsers would ignore it in the case of text/html but I think this was some long time ago at this point (and I’m going to bed soon so I’m not going to start testing a whole bunch of browsers right now; maybe later).
RFC 2616 also mentions the possibility of extension tokens, and these days most browsers recognise inline to mean you do want the entity displayed if possible (that is, if it’s a type the browser knows how to display, otherwise it’s got no choice in the matter). This is of course the default behaviour anyway, but it means that you can include the filename part of the header, which browsers will use (perhaps with some adjustment so file-extensions match local system norms for the content-type in question, perhaps not) as the suggestion if the user tries to save.
Means «I don’t know what the hell this is. Please save it as a file, preferably named picture.png».
Means «This is a PNG image. Please save it as a file, preferably named picture.png».
Means «This is a PNG image. Please display it unless you don’t know how to display PNG images. Otherwise, or if the user chooses to save it, we recommend the name picture.png for the file you save it as».
Of those browsers that recognise inline some would always use it, while others would use it if the user had selected «save link as» but not if they’d selected «save» while viewing (or at least IE used to be like that, it may have changed some years ago).
Отдаем файлы эффективно с помощью PHP
1. Используем readfile()
Метод хорош тем, что работает с коробки. Надо только написать свою функцию отправки файла (немного измененный пример из официальной документации):
Таким способом можно отправлять даже большие файлы, так как PHP будет читать файл и сразу отдавать его пользователю по частям. В документации четко сказано, что readfile() не должен создавать проблемы с памятью.
2. Читаем и отправляем файл вручную
Метод использует тот же Drupal при отправке файлов из приватной файловой системы (файлы недоступны напрямую по ссылкам):
3. Используем модуль веб сервера
3a. Apache
Модуль XSendFile позволяет с помощью специального заголовка передать отправку файла самому Apache. Существуют версии по Unix и Windows, под версии 2.0.*, 2.2.* и 2.4.*
В настройках хоста нужно включить перехват заголовка с помощью директивы:
Также можно указать белый список директорий, файлы в которых могут быть обработаны. Важно: если у Вас сервер на базе Windows путь должен включать букву диска в верхнем регистре.
Описание возможных опций на сайте разработчика: https://tn123.org/mod_xsendfile/
Пример отправки файла:
3b. Nginx
Nginx умеет отправлять файлы из коробки через специальный заголовок.
Для корректной работы нужно запретить доступ к папку напрямую через конфигурационный файл:
Пример отправки файла (файл должен находиться в директории /some/path/protected):
Поддерживаемые протоколы и обёртки
Содержание
User Contributed Notes 31 notes
If you want to filter incoming data through php://input use this:
I couldn’t find any documentation to explain how to do this. All the examples I came across suggested that a full and actual URL had to be used (which didn’t work for me).
This seems to work though.
Even though their names will be the same, you can have more than one //memory or //temp stream open concurrently; each time you fopen() such a stream, a NEW stream will be opened independently of the others.
This is hinted at by the fact you don’t add any unique identifier to the path when creating such streams, but isn’t said explicitly.
You can use «php://input» to accept and parse «PUT», «DELETE», etc. requests.
to create a raw tcp listener system i use the following:
now use fgets(STDIN) to read the input. Creates connections pretty quick, works like a charm.Writing can be done using the STDOUT, or just echo. Be aware that you’re completely bypassing the webserver and thus certain variables will not be available.
For reading a XML stream, this will work just fine:
= file_get_contents ( ‘php://input’ );
?>
Then you can parse the XML like this:
?>
PS.: This is particularly useful for receiving mobile originated (MO) SMS messages from cellular phone companies.
Example of how to use the php://input to get raw post data
//read the raw data in
$roughHTTPPOST = file_get_contents(«php://input»);
//parse it into vars
parse_str($roughHTTPPOST);
if you do readfile(«php://input») you will get the length of the post data
* STDIN
* STDOUT
* STDERR
Were introduced in PHP 4.3.0 and are synomous with the fopen(‘php://stdx’) result resource.
Here is a snippet to read compressed raw post data without enabling global variables.
I needed it to read xml posted data submitted by ocs agent. The data was sent as Content-Type: application/x-compressed (zlib compressed data).
It seems related to an old bug which still seems broken :
https://bugs.php.net/bug.php?id=49411
You can decompress (gzip) a input stream by combining wrappers:
I used this method to decompress a gzip stream that was pushed to my webserver
PHP Code:
//read the raw data in
$roughHTTPPOST = file_get_contents(«php://input»);
//parse it into vars
parse_str($roughHTTPPOST);
If you open an HTTP url and the server issues a Location style redirect, the redirected contents will be read but you can’t find out that this has happened.
So if you then parse the returned html and try and rationalise relative URLs you could get it wrong.
For https for windows enable this extension:
I find using file_get_contents with php://input is very handy and efficient. Here is the code:
$request = «»;
$request = file_get_contents(«php://input»);
I don’t need to declare the URL filr string as «r». It automatically handles open the file with read.
A useful way to handle large file uploads is to do something like:
as this avoids using lots of memory just to buffer the file content.
Setting the mime type to «multipart/form-data» raises “PHP Warning: Missing boundary in multipart/form-data POST data in Unknown on line 0” however it seems to work without a problem.
the file:// protocol used in file_get_contents is used as the default for «any unrecognized protocol.» Thus:
will deliver the same as
In PHP 5.4+ you can read multipart data via php://input if you set enable_post_data_reading to Off.
The use of php://temp/maxmemory as a stream counts towards the memory usage of the script; you are not specifying a new memory pool by using this type of stream.
As noted in the documentation however, this stream type will start to write to a file after the specified maxmemory limit is exceeded. This file buffer is NOT observed by the memory limit.
This is handy if you want your script to have a reasonably small memory limit (eg 32MB) but but still be able to handle a huge amount of data in a stream (eg 256MB)
As a practical example:
Each stream pointer to php://memory and php://temp has its own memory allocation, so you can open many stream pointers to store your separated values.
JSON file generated by PHP has application/octet-stream mime type
I have a script that generates a JSON file from data. I have a second script that read files from a directory to take only JSON ones and insert them in DB.
The problem is that the second script detects «application/octet-stream» MIME type from my generated files instead of application/json
I don’t want to allow application/octet-stream MIME type as it can be pretty anything (for security reason: that second script load all json file in the directory (not only the generated ones)).
Is there then anyway to «set» a MIME type for a file?
The code that generate the file :
The code that read JSON files :
1 Answer 1
The fileinfo extension (as similar tools like the file Unix command) basically searches for signatures defined in a database (called «magic»). If I’m not wrong, PHP’s magic database is currently compiled into the extension binary file so you can’t peek at it but you’ll probably have a similar database in your system. I have Apache’s at C:\Apache24\conf.magic and this is the entry for JPEG:
Anything that starts with 0xffd8 is a picture. Done!
I’m not particularly familiar with the format but it doesn’t seem to even look for JSON. And, as you may already be guessing, the overall utility is by no means a security feature. It’s just a helper tool to figure out what a file may contain. It’s very handy if e.g. you’ve recovered files with no extension from a damaged disk.
MIME types are cool. You set application/json and everybody knows it’s JSON. Straightforward and simple, isn’t it. There’re only two caveats:
File systems (many of them actually invented before MIME types) store many file attributes (name, last modification date, permissions, sometimes even icons. ) but not MIME types. (Sure, there’s probably some academic file system that does, but it’s not the case of FAT32, NTFS, ext4. ). It doesn’t normally add valuable information, it’s yet another token to keep updated and it’s particularly non-portable (copy your files to a thumb drive and they’re gone).
It’s still not a security feature. If I can forge the file contents, what prevents me from forging the MIME type?
So, what can you do? The best alternative is: nothing at all.