#contenttype

概述_ ajax 與 FormData

進行行動網站的bug修改時，遇到其中一個需求是原本只使用 ajax 上傳string格式的input資料，但因為功能擴充除了原本的值要上傳外還需要上傳檔案類型的資料，大部分人都知道，使用 ajax 上傳圖片或檔案需要使用js的FormData物件，若是 ajax 傳遞的資料不包含檔案類型的則基本上都是使用一般的js物件傳遞即可。但其實很多人在遇到同時要傳遞一般input資料及檔案時就會猶豫要如何處理，或是直接將兩件事情分開來做，一是不知道後端如何處理，二是formdata傳送方法的前端return不像一般ajax可設定return物件要被解析的類型（例如text或json)，導致有許多人會搞不懂其運作模式，但其實字串跟檔案是可以透過formdata一起傳送到後端處理的，為了讓大家使用上邏輯更為清晰所以撰寫此篇文章作為紀錄。

I recently spent a couple of days working with XDomainRequests. This is the legacy technology that allow you to do cross origin requests (CORS) on Internet Explorer 8 and 9. To explain CORS further: if you have a web app available through “myfirstdomain.com” and that web app, once it is loaded in the browser, sends a request to an API that is available on “myseconddomain.com”, that is CORS. Requests between different domains.

Now, this blogs title is “makeitnew.io”, and I will be the first to admit that this posts relevance might be missing. But as it took me a really long time to find a solution for this in my network, and on Google, I feel that I need to write this post to help the next person, implementing legacy browser support for his REST API, to get this problem solved more quickly.

The Problem

My issue manifested itself after deploying a piece of client side JavaScript that supported XDomainRequests to all our clients. Suddenly alerts about a huge spike in 400 errors filled our system health channel on slack. The number of errors, and the lack of decrease in HTTP response 200, makes it relatively clear that most of the extra traffic we were expecting to get from rolling out support for IE8 and IE9 are all coming in as errors.

I immediately rolled back the change. After the back end looks healthy again, I immediately started looking for reasons why this would happen. Former Microsoft employee Eric Law has written probably the most comprehensible guide to XDomainRequests, and I read through it with a looking glass to find possible explanations.

The first likely culprit is that XDomainRequests are supposed to send requests with the content-type “text/plain” in the header. Yes, I missed the note in Eric Law’s post saying that as of 2014 no content-type seems to be sent. So anyways, I open Postman and start sending requests with the culprit content-type and get 400s back. Time for a pull request on our collector service.

So after setting up everything I need to test locally, I add support for body-parser to parse text/plain on our Node.js / Express back end collection service. Still just 400 back. WAT.

So I am using Internet Explorer 11 in IE9 emulation mode for sending the requests. And the request bodies being sent appear empty. I enable some logging in the console. And, no, the request body is not at all empty. Weirdness is going on here. I get some logging going on my local fork of the collection service. And yes, the requests are in fact empty except for the header.

At this point I am confused and I start reaching out to both my network and Google to figure out if others have experienced the same problem. And there is not much help to be had. I find some colleagues that have experienced something similar and have solved it by creating a proxy for requests with the same domain as their service. Allowing them to use XmlHttpRequests in old Internet Explorer instead. As the script I am making is running across a lot of different domains that I do not control, this is not an alternative. So I keep on Googling.

My breakthrough comes when a colleague suggests that I use PyProxy. After firing up Wireshark (because that was what I had installed) and sending some packages, I discover two things. First, that there are infact a request body that looks healthy. And secondly that the content-type is missing.

The Solution

After realising the issue was actually the content-type missing, I was able to find a package called “express-content-type-override”. And while it was not perfect, it was enough to fix the problem for my case.

What the aforementioned package lacks to account for, is that the charset also goes in the content-type. That caused some initial problems that was quick to find and fix.

I also submitted a pull request for this: https://github.com/rbartoli/express-content-type-override/pull/1

What is important is that the content type is checked and modified before bodyParser is added to as middleware.

Example

This code is all in the server.js file. Which is where the routing happens in the mentioned application.

This is put in the top of the file, together with the rest of the required packages.

var contentTypeOverride = require('express-content-type-override');

The middleware is applied right before the routing happens:

// Handle XDomainRequests coming in without content-type header. app.use('/api/send', contentTypeOverride({ contentType: 'application/json', charset: 'utf-8' })); var apiSendRouter = require('./routes/api-send'); app.use('/api/send', apiSendRouter);

Parsing of the body happens inside the required file for the path (./routes/api-send)

About the author

Here is a Quick how to export a contenttype filtered out by a contenttype group "CT Test".

$sourceWeb = Get-SPWeb http://url/site/subsite $xmlFilePath = "C:\Install\Script-SiteContentTypes.xml"

#Create Export File New-Item $xmlFilePath -type file -force

#Export Content Types to XML file Add-Content $xmlFilePath "<?xml version=`"1.0`" encoding=`"utf-8`"?>" Add-Content $xmlFilePath "`n<ContentTypes>" $sourceWeb.ContentTypes | ForEach-Object {     if ($_.Group -eq "CT Test") {         Add-Content $xmlFilePath $_.SchemaXml     } } Add-Content $xmlFilePath "</ContentTypes>"

$sourceWeb.Dispose()

This will export the Contenttype definition in a xml file. 

When you want to import this contenttype into another site you mus use the following PowerShell code

# The destination site 

$destWeb = Get-SPWeb http://portal/sites/migrationtest

#Create Site Content Types $ctsXML = [xml](Get-Content($xmlFilePath)) $ctsXML.ContentTypes.ContentType | ForEach-Object {

    #Create Content Type object inheriting from parent     $spContentType = New-Object Microsoft.SharePoint.SPContentType ($_.ID,$destWeb.ContentTypes,$_.Name)          #Set Content Type description and group     $spContentType.Description = $_.Description     $spContentType.Group = $_.Group          $_.Fields.Field  | ForEach-Object {         if(!$spContentType.FieldLinks[$_.DisplayName])         {             #Create a field link for the Content Type by getting an existing column             $spFieldLink = New-Object Microsoft.SharePoint.SPFieldLink ($destWeb.Fields[$_.DisplayName])                      #Check to see if column should be Optional, Required or Hidden             if ($_.Required -eq "TRUE") {$spFieldLink.Required = $true}             if ($_.Hidden -eq "TRUE") {$spFieldLink.Hidden = $true}                      #Add column to Content Type             $spContentType.FieldLinks.Add($spFieldLink)         }     }          #Create Content Type on the site and update Content Type object     $ct = $destWeb.ContentTypes.Add($spContentType)     $spContentType.Update()     write-host "Content type" $ct.Name "has been created" }

$destWeb.Dispose()

This will parse the XMl and add them to the new site. After that you will hopefully copied  the contenttype into the new location. 

I wanted to remove a not used contenttype from my SharePoint Site. 

When I want to remove it I got the error message like in the title in this blog. The solution was quite simple. 

Mục đích: Ví dụ từ link http://lienxo.my/xxx.jpg thì contentType="image/jpeg".

Cách làm

// Chuyển về chữ thường http://lienxo.my/xxx.JPG -> http://lienxo.my/xxx.jpg mstrPhotoPath = mstrPhotoPath.toLowerCase(Locale.UK);

// Lấy đuôi file từ url String extensionFile = MimeTypeMap.getFileExtensionFromUrl(mstrPhotoPath);

// Lấy contentType String contentType = MimeTypeMap.getSingleton()                 .getMimeTypeFromExtension(extensionFile);

This is very annoying. While I do agree that real world scenario of someone wanting to view json content on a browser doesn't occur frequently, I would like for that to be possible as a debugging measure. I'm doing a padded json call from my client application.  Troubleshooting requires that I inspect the json response that is being sent from my server side component.

So I had my response type set text/json as below in my server side code which is in AjaxProxy.ashx

C# -> context.Response.ContentType = "text/json";

if I try to view the server side page http://lservername/AjaxProxy.ashx in IE8, it manages to make a mess of it and fails trying to interpret my perfectly valid json Response as XML

Chrome and Firefox tries to download the file (which is still better that IE behavior). But I prefer to be able to just view it in the browser. The correct content type for json is application/json. So below mentioned content type setting shows the json response properly on Chrome and Firefox.

C# -> context.Response.ContentType = "application/json";

IE8 still has the same issue as earlier and this really is an IE bug. application/json is indeed the recommended response content type for json response. 

But if you re not bothered and just want to be able to see it in IE8 , then by all means set the content type to "text/plain"