I have activated CMIS in a SharePoint 2013 hosted in IIS 8.5, the problem is that I'm able to invoke the SOAP services but the response is always returned with Content-Type: multi-part / related which is not supported by the source application (and it won't).
Could anybody please help me to disable the multi-part content-type? I have search about it for days and I have been exploring all the SharePoint and IIS options without any luck.
The problem is also that I'm not sure who is sending it as multi-part: CMIS, SharePoint, IIS... although I think is IIS as I at least could change the response header adding a custom header from IIS, but I don't find any way to disable the multi-part thing...
This is an example, ignore the response content...
Cache-Control: private
Content-Length: 998
**Content-Type: multipart/related;** type="application/xop+xml";start="<http://tempuri.org/0>";boundary="uuid:4748e8de-7139-47e4-914e-1d42beac1762+id=2";start-info="text/xml"
Server: Microsoft-IIS/8.5
X-SharePointHealthScore: 0
MIME-Version: 1.0
X-AspNet-Version: 4.0.30319
SPRequestGuid: ec016e9d-8e7d-7035-4d00-69b3136bea29
request-id: ec016e9d-8e7d-7035-4d00-69b3136bea29
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 41
SPIisLatency: 4
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4569
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 31 Mar 2016 18:31:38 GMT
**--uuid:4748e8de-7139-47e4-914e-1d42beac1762+id=2**
Content-ID: <http://tempuri.org/0>
Content-Transfer-Encoding: 8bit
Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
.......
....
....
Thank you.
UPDATE:
I discovered that the Service is deployed as WCF Service (.svc), so the new question is:
How can I change the messageEncoding to "Text" for all the Operations in an Service that I have no access to the code and is deployed as .svc?
ServiceName = ObjectService
Binding = ObjectServicePortBinding
I would be surprised if you can turn it off. The CMIS specification mandates the use of MTOM (multipart). And it's actually necessary to transfer document content.
I'm finally using the REST API instead of SOAP, so the problem has disappeared, although I'll never know the answer to the original question :(
Related
We’re getting an error – “unable to convert document” for one of our clients on our multi-tenant server. I’ve had a rummage and it looks like that error is generated when you’re sending a file with an unexpected extension meaning that DocuSign doesn’t know how to convert it to a PDF (https://stackoverflow.com/questions/53771197/docusign-random-unable-to-convert-document-error). What I’m failing to understand is how it can be working for some – it works for me on our multi-tenant server – but not others. Is there more to this than meets the eye or am I missing something?
Headers : X-RateLimit-Reset: 1573833600
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 991
X-DocuSign-TraceToken: #####
Strict-Transport-Security: max-age=31536000; includeSubDomains
Cache-Control: no-cache
Date: Fri, 15 Nov 2019 15:20:40 GMT
Response stream : {
"errorCode": "UNABLE_TO_CONVERT_DOCUMENT",
"message": "System was unable to convert this document to a PDF. Unable to convert Document(2019.11.15_NDA - MyDocument) to a PDF. Error: UserId:##### IPAddress:##### Source:ApiRESTv2:FileType 15_nda - my document is ineligible for conversion."
}
Check that you are setting the fileExtension attribute to pdf in the document object in your Envelopes::create call.
If you don't set it, DocuSign does some guessing, but setting the attribute explicitly is the way to go.
I'm trying to get my header rounder Caching. I have the following code in vb.net:
With HttpContext.Current.Response
.Cache.SetCacheability(HttpCacheability.Public)
.Cache.SetRevalidation(HttpCacheRevalidation.AllCaches)
.Cache.SetLastModified(Now)
.Cache.SetExpires(DateTime.UtcNow.AddSeconds(120))
.Cache.SetMaxAge(TimeSpan.FromSeconds(120))
End With
Which returns the following headers:
Cache-Control: public, no-cache="Set-Cookie", must-revalidate, max-age=120
Content-Type: application/xml; charset=utf-8
Expires: Mon, 22 Aug 2016 13:54:36 GMT
Last-Modified: Mon, 22 Aug 2016 13:52:36 GMT
But I'm trying to figure out what is setting no-cache="Set-Cookie" and how can I switch that on or off?
The no-cache="Set-Cookie" tells the browser not to cache the server "Set-Cookie" header, but follow different rules for the rest of the request.
Here's a discussion from W3C
http://www.w3.org/Protocols/HTTP/Issues/cache-private.html
In http 1.1, Roy has proposed some features for the new cache-control
directive that allow servers to selectively disable caching on
specific headers. This would be, for example:
cache-control: no-cache="set-cookie"
i am trying to return a BadArguments Error along with a custom DTO in the body:
var result = new HttpResult(response, "application/json", HttpStatusCode.BadRequest);
I have tried to use HttpError, HttpResult, setting the response by hand etc etc but i get only
HTTP/1.1 400 BadRequest
Cache-Control: private
Transfer-Encoding: chunked
Content-Type: text/html
Server: Microsoft-IIS/7.5
X-Powered-By: ServiceStack/3,22 Win32NT/.NET
X-Powered-On: ITDEVELOP36-PC
Test-Header-ValidationError: TestValidationError
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Thu, 26 Feb 2015 10:36:12 GMT
b
Bad Request
0
No body, no content type is set. What am i missing?
ServiceStack version is 3.3.6.29935.
After poking a while i have found that the ServiceStack framework works just fine. Even in the older version we are using.
The issue exist only when the web.config enables the section.
After removing this section all worked well.
I'm currently trying to pass PCI compliance for one of my client's sites but the testing company are flagging up a vulnerability that I don't understand!
The (site removed) details from the testing company are as follows:
The issue here is a cross-site
scripting vulnerability that is
commonly associated with e-commerce
applications. One of the tests
appended a harmless script in a GET
request on the end of the your site
url. It flagged as a cross-site
scripting vulnerability because this
same script that was entered by the
user (our scanner) was returned by the
server unsanitized in the header. In
this case, the script was returned in
the header so our scanner flagged the
vulnerability.
Here is the test I ran from my
terminal to duplicate this:
GET
/?osCsid=%22%3E%3Ciframe%20src=foo%3E%3C/iframe%3E
HTTP/1.0 Host:(removed)
HTTP/1.1 302 Found
Connection: close
Date: Tue, 11 Jan 2011 23:33:19 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Location: http://www.(removed).co.uk/index.aspx?osCsid="><iframe src=foo></iframe>
Set-Cookie: ASP.NET_SessionId=bc3wq445qgovuk45ox5qdh55; path=/; HttpOnly
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 203
<html><head><title>Object moved</title></head><body>
<h2>Object moved to here.</h2>
</body></html>
The solution to this issue is to
sanitize user input on these types of
requests, making sure characters that
could trigger executable scripts are
not returned on the header or page.
Firstly, I can't get the result that the tester did, it only ever returns a 200 header which doesn't include the location, nor will it return the object moved page. Secondly, i'm not sure how (on iis 6) to stop it returning a header with the query string in it! Lastly, why does code in the header matter, surely browsers wouldn't actually execute code from the http header?
Request: GET /?osCsid=%22%3E%3Ciframe%20src=foo%3E%3C/iframe%3E HTTP/1.0 Host:(removed)
The <iframe src=foo></iframe> is the issue here.
Response text:
<html><head><title>Object moved</title></head><body>
<h2>Object moved to here.</h2>
</body></html>
The response link is:
http://www.(removed).co.uk/index.aspx?osCsid="><iframe src=foo></iframe>
Which contains the contents from the request string.
Basically, someone can send someone else a link where your osCsid contains text that allows the page to be rendered in a different way. You need to make sure that osCsid sanitizes input or filters against things that could be like this. For example, I could provide a string that lets me load in whatever javascript I want, or make the page render entirely different.
As a side note, it tries to forward your browser to that non-existent page.
It turned out that I have a Response.redirect for any pages which are accessed by https which don't need to be secure and this was returning the location as part of the redirect. Changing this to:
Response.Status = "301 Moved Permanently";
Response.AddHeader("Location", Request.Url.AbsoluteUri.Replace("https:", "http:"));
Response.End();
Fixed the issue
With the help of HttpWatch, I tried to figure out how GMail implements Comet.
I login in to GMail with two accounts, one in IE and the other in Firefox. Chatting in GTalk in GMail with some magic words like "WASSUP". Then, I logoff both GMail accounts, filter any http content without "WASSUP" string. The result shows which HTTP request is the streaming channel. (Note: I have to logoff. Otherwise, never-ending HTTP would not show content in HttpWatch.)
The result is interesting. The URL for stream channel is like:
https://mail/channel/bind?VER=8&at=xn3j33vcvk39lkfq.....
There is no surprise that GMail do Comet in IE with IFRAME. The Http content starts with "<html><body>".
Originally, I guessed that GMail does Comet in Firefox with multipart XmlHttpRequest. To my surprise, the response header doesn't have "multipart/x-mixed-replace" header. The response headers are as below:
HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Date: Sat, 20 Mar 2010 01:52:39 GMT
X-Frame-Options: ALLOWALL
Transfer-Encoding: chunked
X-Content-Type-Options: nosniff
Server: GSE
X-XSS-Protection: 0
Unfortunately, the HttpWatch doesn't tell whether a HTTP request is from XmlHttpRequest or not. The content is not HTML but JSON. It looks like a response for XHR, but that would not work for Comet without multipart/x-mixed-replace, right?
Is there any way else to figure out how GMail implements Comet?
Update:
After further investigation, I believe GMail implements Comet this way:
1) in IE, it use a forever-hidden-iframe;
2) in Firefox, it use forever-XHR without multipart/x-mixed-replace header. The client will response in conditon (readyState == 3) OR (readyState == 4). That is, in both interactive state and complete state.
Per this article,
So what is the solution used by Google
Gmail?
The solution is really simple,
straight forward and very portable!
What Gmail did is requesting an
endless html page that contains
streams of Javascript portions. Give
it a try, It’s very powerful. So, we
will have on the client side a js file
that processes the responses, and
another endless html that contains the
Javascript Streams.
The rest of the article goes into much more detail, including an exploration of alternatives as well as the specific one picked by GMail.