What Is Application Octet Stream

Understand that the 'application/octet-stream' MIME type is generated (sometimes) when a file is viewed or save in a word process or spreadsheet application. The question is. Are there security concerns if I. Application / octet-stream file Respected, When I send mail, the application / octet-stream file is always attached, I do not attach it, it is self-ported, I wonder what it is about? Apr 25, 2018 Under: Content Type Breakdown is are: empty - I think this is like 301,404,410 Server request but what is octet-stream? My first idea was a pdf but the request are to high. I don’t have any file like audi or video files on my server. Most people chose this as the best definition of application-octet-stream: See bitstream. See the dictionary meaning, pronunciation, and sentence examples.

• What Is Application/octet-stream Files
• What Is Application/octet-stream Files
• Application Octet Stream Download
• How To Open Octet Stream File
• What Is Application/octet-stream Files

MIME types describe the media type of content, either in email, or served by web servers or web applications. They are intended to help provide a hint as to how the content should be processed and displayed.

Examples of MIME types:

• text/html for HTML documents.
• text/plain for plain text.
• text/css for Cascading Style Sheets.
• text/javascript for JavaScript files.
• text/markdown for Markdown files.
• application/octet-stream for binary files where user action is expected.

Server default configurations vary wildly and set different default MIME-type values for files with no defined content type.

Versions of the Apache Web Server before before 2.2.7 were configured to report a MIME type of text/plain or application/octet-stream for unknown content types. Modern versions of Apache report none for files with unknown content types.

Nginx will report text/plain if you don't define a default content type.

As new content types are invented or added to web servers, web administrators may fail to add the new MIME types to their web server's configuration. This is a major source of problems for users of browsers that respect the MIME types reported by web servers and applications.

If a web server or application reports an incorrect MIME type for content (including a 'default type' for unknown content), a web browser has no way of knowing the author's intentions. This may cause unexpected behavior.

Some web browsers, such as Internet Explorer, try to guess the correct MIME type. This allows misconfigured web servers and applications to continue working for those browsers (but not other browsers that correctly implement the standard). Apart from violating the HTTP spec, this is a bad idea for a couple of other significant reasons:

Loss of control

If the browser ignores the reported MIME type, web administrators and authors no longer have control over how their content is to be processed.

For example, a web site oriented for web developers might wish to send certain example HTML documents as either text/html or text/plain in order to have the documents either processed and displayed as HTML or as source code. If the browser guesses the MIME type, this option is no longer available to the author.

Security

Some content types, such as executable programs, are inherently unsafe. For this reason, these MIME types are usually restricted in terms of what actions a web browser will take when given that type of content. An executable program should not be executed on the user's computer and should at least cause a dialog to appear asking the user if they wish to download the file.

MIME type guessing has led to security exploits in Internet Explorer that were based upon a malicious author incorrectly reporting a MIME type of a dangerous file as a safe type. This bypassed the normal download dialog, resulting in Internet Explorer guessing that the content was an executable program and then running it on the user's computer.

When looking for information about JavaScript MIME types, you may see several MIME types that reference JavaScript. Some of these MIME types include:

• application/javascript
• application/ecmascript
• application/x-ecmascript
• application/x-javascript
• text/ecmascript
• text/javascript1.0
• text/javascript1.1
• text/javascript1.2
• text/javascript1.3
• text/javascript1.4
• text/javascript1.5
• text/x-ecmascript
• text/x-javascript

While browsers may support any, some, or all of these alternative MIME types, you should only use text/javascript to indicate the MIME type of JavaScript files.

Note: See MIME types (IANA media types) for more information.

There are several ways to determine the correct MIME type value to be used to serve your content.

• If your content was created using commerical software, read the vendor's documentation to see what MIME types should be reported for the application.
• Look in IANA's MIME Media Types registry, which contains information on all registered MIME types.
• Search for the file extension in FILExt or the File extensions reference to see what MIME types are associated with that extension. Pay close attention as the application may have multiple MIME types that differ by only one letter.

• In Firefox
  • Load the file and go to Tools > Page Info to get the content type for the page you accessed.
  • You can also go to Tools > Web Developer > Network and reload the page. The request tab gives you a list of all the resources the page loaded. Clicking on any resource will list all the information available, including the page's Content-Typeheader.
• In Chrome
  • Load the file and go to View > Developer > Developer Tools and choose the Network tab. Reload the page and select the resource you want to inspect. Under headers look for Content-Type and it will report the content type of the resource.
• Look for a <meta> element in the page source that gives the MIME type, for example <meta http-equiv='Content-Type'>.
  • According to the standards, the <meta> element that specifies the MIME type should be ignored if there's a Content-Type header available.

IANA keeps a list of registered MIME Media Types. The HTTP specification defines a superset of MIME types, which is used to describe the media types used on the web.

The goal is to configure your server to send the correct Content-Type header for each document.

• If you're using the Apache web server, check the Media Types and Character Encodings section of Apache Configuration: .htaccess for examples of different document types and their corresponding MIME types.
• If you're using NGINX, look at the NGINX configuration snippets. NGINX does not have a .htaccess equivalent tool, so all changes will go into the main configuration file.
• If you're using a server-side script or framework to generate content, the way to indicate the content type will depend on the tool you're using. Check the framework or library's documentation.

by

Handling data from Azure Storage blobs is not straightforward. The return value is binary (application/octet-stream) at first and needs to be casted into a data type you want to process; in our case into application/json.

This write-up is an easy to follow and real walk through of errors beginners may encounter handling Azure Storage blobs in Azure Logic Apps. It has happened to me.

As soon a new file (blob) in an Azure Storage container arrives this file should be processed by an Azure Function app.

1) Create a new Azure Storage Account.
2) Create a new container in the storage account.
3) Create a new Azure Logic App.
4) Design the Logic App.

A first draft could look like this.

With this configuration we have three steps.

1. When one or more blobs are added or modified (metadata only) (Preview)
   • Created a connection to the newly created storage account.
   • Configured to look in the container files.
   • Configured to look for changes every 10 seconds.
2. Get blob content
   • Gets the content of a blob by ID. (There is a similar action called “Get blob content using path” if you need to get blob contents via paths.)
3. Azure Function
   • We call an Azure Function with the content of the blob.

Unfortunately, this configuration does not work because of two errors:

1. there is no array of blobs
2. data type issues

I use the Microsoft Azure Storage Explorer to upload files into the container of my Azure Storage account to trigger my Azure Logic App. In every try I increment the number of my test file. The test file contains a simple JSON which can be interpreted by my Azure Function.

After each upload I go back into the Azure Portal to look for new trigger events and shortly afterwards for new run events. To avoid flooding of my trigger history I disable the logic app after each upload to inspect the run results. Before each new try I enable the logic app again.

As you can see our first configuration of the Azure Logic App did not run successfully. Let’s inspect the first error!

The return value of the first step is no array! If we look at the raw data, we see in the body that there is no array. Maybe this is an exception because we uploaded only a single file? Try again with two files at the same time.

Now, I upload two files at the same time.

Surprisingly, the Logic App gets triggered for each new file separately.

So my assumption was wrong that the action When one or more blobs are added or modified (metadata only) (Preview) returns an array. For me the property Number of blobs was somewhat misleading that the action would return an array.

We can resolve this error easily by removing the for-each-loop. We can design the flow of the Logic App in such a way that the Logic App gets triggered for each new or modified blob separately.

Let’s try again by uploading a new file. Again, we see in the run history an error. This time the error is at the third step. The first two steps are running successfully, now. We were successful in getting the content of the blob which has triggered the Logic App. So far, so good! Let’s explore the new error!

Even the raw data of the 2nd step looks fine.

Examples of MIME types:

• text/html for HTML documents.
• text/plain for plain text.
• text/css for Cascading Style Sheets.
• text/javascript for JavaScript files.
• text/markdown for Markdown files.
• application/octet-stream for binary files where user action is expected.

Server default configurations vary wildly and set different default MIME-type values for files with no defined content type.

Versions of the Apache Web Server before before 2.2.7 were configured to report a MIME type of text/plain or application/octet-stream for unknown content types. Modern versions of Apache report none for files with unknown content types.

Nginx will report text/plain if you don't define a default content type.

As new content types are invented or added to web servers, web administrators may fail to add the new MIME types to their web server's configuration. This is a major source of problems for users of browsers that respect the MIME types reported by web servers and applications.

If a web server or application reports an incorrect MIME type for content (including a 'default type' for unknown content), a web browser has no way of knowing the author's intentions. This may cause unexpected behavior.

Some web browsers, such as Internet Explorer, try to guess the correct MIME type. This allows misconfigured web servers and applications to continue working for those browsers (but not other browsers that correctly implement the standard). Apart from violating the HTTP spec, this is a bad idea for a couple of other significant reasons:

Loss of control

If the browser ignores the reported MIME type, web administrators and authors no longer have control over how their content is to be processed.

For example, a web site oriented for web developers might wish to send certain example HTML documents as either text/html or text/plain in order to have the documents either processed and displayed as HTML or as source code. If the browser guesses the MIME type, this option is no longer available to the author.

Security

Some content types, such as executable programs, are inherently unsafe. For this reason, these MIME types are usually restricted in terms of what actions a web browser will take when given that type of content. An executable program should not be executed on the user's computer and should at least cause a dialog to appear asking the user if they wish to download the file.

MIME type guessing has led to security exploits in Internet Explorer that were based upon a malicious author incorrectly reporting a MIME type of a dangerous file as a safe type. This bypassed the normal download dialog, resulting in Internet Explorer guessing that the content was an executable program and then running it on the user's computer.

When looking for information about JavaScript MIME types, you may see several MIME types that reference JavaScript. Some of these MIME types include:

• application/javascript
• application/ecmascript
• application/x-ecmascript
• application/x-javascript
• text/ecmascript
• text/javascript1.0
• text/javascript1.1
• text/javascript1.2
• text/javascript1.3
• text/javascript1.4
• text/javascript1.5
• text/x-ecmascript
• text/x-javascript

While browsers may support any, some, or all of these alternative MIME types, you should only use text/javascript to indicate the MIME type of JavaScript files.

Note: See MIME types (IANA media types) for more information.

There are several ways to determine the correct MIME type value to be used to serve your content.

• If your content was created using commerical software, read the vendor's documentation to see what MIME types should be reported for the application.
• Look in IANA's MIME Media Types registry, which contains information on all registered MIME types.
• Search for the file extension in FILExt or the File extensions reference to see what MIME types are associated with that extension. Pay close attention as the application may have multiple MIME types that differ by only one letter.

• In Firefox
  • Load the file and go to Tools > Page Info to get the content type for the page you accessed.
  • You can also go to Tools > Web Developer > Network and reload the page. The request tab gives you a list of all the resources the page loaded. Clicking on any resource will list all the information available, including the page's Content-Typeheader.
• In Chrome
  • Load the file and go to View > Developer > Developer Tools and choose the Network tab. Reload the page and select the resource you want to inspect. Under headers look for Content-Type and it will report the content type of the resource.
• Look for a <meta> element in the page source that gives the MIME type, for example <meta http-equiv='Content-Type'>.
  • According to the standards, the <meta> element that specifies the MIME type should be ignored if there's a Content-Type header available.

IANA keeps a list of registered MIME Media Types. The HTTP specification defines a superset of MIME types, which is used to describe the media types used on the web.

The goal is to configure your server to send the correct Content-Type header for each document.

• If you're using the Apache web server, check the Media Types and Character Encodings section of Apache Configuration: .htaccess for examples of different document types and their corresponding MIME types.
• If you're using NGINX, look at the NGINX configuration snippets. NGINX does not have a .htaccess equivalent tool, so all changes will go into the main configuration file.
• If you're using a server-side script or framework to generate content, the way to indicate the content type will depend on the tool you're using. Check the framework or library's documentation.

by

Handling data from Azure Storage blobs is not straightforward. The return value is binary (application/octet-stream) at first and needs to be casted into a data type you want to process; in our case into application/json.

This write-up is an easy to follow and real walk through of errors beginners may encounter handling Azure Storage blobs in Azure Logic Apps. It has happened to me.

As soon a new file (blob) in an Azure Storage container arrives this file should be processed by an Azure Function app.

1) Create a new Azure Storage Account.
2) Create a new container in the storage account.
3) Create a new Azure Logic App.
4) Design the Logic App.

A first draft could look like this.

With this configuration we have three steps.

1. When one or more blobs are added or modified (metadata only) (Preview)
   • Created a connection to the newly created storage account.
   • Configured to look in the container files.
   • Configured to look for changes every 10 seconds.
2. Get blob content
   • Gets the content of a blob by ID. (There is a similar action called “Get blob content using path” if you need to get blob contents via paths.)
3. Azure Function
   • We call an Azure Function with the content of the blob.

Unfortunately, this configuration does not work because of two errors:

1. there is no array of blobs
2. data type issues

I use the Microsoft Azure Storage Explorer to upload files into the container of my Azure Storage account to trigger my Azure Logic App. In every try I increment the number of my test file. The test file contains a simple JSON which can be interpreted by my Azure Function.

After each upload I go back into the Azure Portal to look for new trigger events and shortly afterwards for new run events. To avoid flooding of my trigger history I disable the logic app after each upload to inspect the run results. Before each new try I enable the logic app again.

As you can see our first configuration of the Azure Logic App did not run successfully. Let’s inspect the first error!

The return value of the first step is no array! If we look at the raw data, we see in the body that there is no array. Maybe this is an exception because we uploaded only a single file? Try again with two files at the same time.

Now, I upload two files at the same time.

Surprisingly, the Logic App gets triggered for each new file separately.

So my assumption was wrong that the action When one or more blobs are added or modified (metadata only) (Preview) returns an array. For me the property Number of blobs was somewhat misleading that the action would return an array.

We can resolve this error easily by removing the for-each-loop. We can design the flow of the Logic App in such a way that the Logic App gets triggered for each new or modified blob separately.

Let’s try again by uploading a new file. Again, we see in the run history an error. This time the error is at the third step. The first two steps are running successfully, now. We were successful in getting the content of the blob which has triggered the Logic App. So far, so good! Let’s explore the new error!

Even the raw data of the 2nd step looks fine.

The Azure Function action in the third step throws the error UnsupportedMediaType with the message: “The WebHook request must contain an entity body formatted as JSON.” That error may be confusing at first because our file contains pure JSON data. A look at the content type reveals that the Logic App does not know that we handle JSON data, instead it says something of application/octet-stream, which is a binary data type.

The Azure Function gets the following raw input:

The raw output of the Azure Function action looks like this.

And for reference the function stub of the Azure Function looks like this:

The documentation states, that Logic Apps can handle natively application/json and text/plain (see Handle content types in logic apps). As we have already JSON data we can use the function @json() to cast the data type to application/json.

Unfortunately, this approach cannot be saved by the Logic App Designer.

Error message

Save logic app failedFailed to save logic app logicapp. The template validation failed: ‘The template action ‘ProcessBlob2’ at line ‘1’ and column ‘43845’ is not valid: “The template language expression ‘json(@{body(‘Get_blob_content’)})’ is not valid: the string character ‘@’ at position ‘5’ is not expected.”.’.

Fortunately, this only a small shortcoming of the Azure Logic App Designer. We need to look at the configuration in code view. For that reason click on the tree dots ... in the upper right corner of the Azure Function action and select Peek code in the menu.

We have to change the evaluation in the body property. It must not contain more than one expression wrapper @(). The documentation does not say explicitly how to nest expressions (see https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-workflow-definition-language#expressions), but after some trial and error, we know, we just need to remove the nested expression wrapper @{and } and leave everything else.

Check again, if it’s working. Upload a new file.

We check the run history, again, and all actions did run successfully. Let’s check the raw input and output.

Raw input:

Raw output:

There is a difference in the input data of the Azure Function action, as there is no explicit content type, just pure JSON data.

The final Logic App looks like this in the designer. Unfortunately, you don’t see all expressions. You need to peek inside the code, as seen in the step before.

To see everything switch to code view. That’s not nice to design, but it’s good enough to check our configuration.

• https://stackoverflow.com/questions/10399324/where-is-httpcontent-readasasync#=