WebDAV Word Upload Failed (but works)... Does MS Word Require WebDAV Microsoft Extension Properties (e.g. office:modifiedby) - asp.net

tl;dr
Do you need to implement the Microsoft WebDav Extension Properties to properly work with Word.
Extended Question
I'm building out a WebDav server ontop of the pre-existing WebDAV.NET open source project. I noticed that with Word 2010 (didn't try other versions) their sample code doesn't correctly handle saving Microsoft Word documents as it will say "Upload failed" even though the document saves correctly and you are the only user of the file. I'm trying to track down the reason why, and one thing that caught my eye was the Microsoft WebDav Extension Properties. The MS page for this states that "A WebDAV server implementing WebDAV Protocol: Microsoft Extensions SHOULD implement the following extended properties." Since it states should, I would assume you do not have to support it to work with Word.
I became suspicious of the extensions when I noted that my propfind request/response looks like the following:
PROPFIND /test123.docx HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Content-Type: text/xml; charset="utf-8"
User-Agent: Microsoft Office Core Storage Infrastructure/1.0
Depth: 0
Translate: f
Connection: Keep-Alive
Content-Length: 208
Host: localhost:62954
<?xml version="1.0" encoding="utf-8" ?><D:propfind xmlns:D="DAV:" xmlns:Office="urn:schemas-microsoft-com:office:office"><D:prop><D:creationdate/><D:getlastmodified/><Office:modifiedby/></D:prop></D:propfind>
HTTP/1.1 207 Multi-Status
Server: ASP.NET Development Server/10.0.0.0
Date: Mon, 16 Apr 2012 14:11:55 GMT
X-AspNet-Version: 4.0.30319
MS-Author-Via: DAV
Cache-Control: private
Content-Type: text/xml; charset=utf-8
Content-Length: 576
Connection: Close
<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://localhost:62954/test123.docx</D:href>
<D:propstat>
<D:prop>
<D:creationdate>2012-04-10T08:00:00Z</D:creationdate>
<D:getlastmodified>2012-04-16T09:09:44Z</D:getlastmodified>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:status>HTTP/1.1 404 Not Found</D:status>
<D:prop>
<modifiedby xmlns="urn:schemas-microsoft-com:office:office" />
</D:prop>
</D:propstat>
</D:response>
</D:multistatus>
In case anyone is curious, the following is my PUT response.
HTTP/1.1 200 OK
Server: ASP.NET Development Server/10.0.0.0
Date: Mon, 16 Apr 2012 14:18:06 GMT
X-AspNet-Version: 4.0.30319
MS-Author-Via: DAV
Cache-Control: private
Content-Length: 0
Connection: Close

By the way, I found the bug in Sphorium webdav that was causing this. The bug was in the method DavLockBase_InternalProcessDavRequest() and the incorrect line of code was:
string[] _lockTokens = this.RequestLock.GetLockTokens();
which should be:
string[] _lockTokens = this.ResponseLock.GetLockTokens();

No, you don't need to implement the Microsoft WebDAV Extension Properties.
(I figured out the answer to my own question)
The issue with WebDAV.NET is that there is a bug in it that an empty LockToken in the header which confuses Word and makes it not give the LockToken to the PUT request.

Related

POST https://www.linkedin.com/uas/oauth2/accessToken HTTP/1.1 results in Method Not Found on LinkedIn

I am using the LinkedIn Owin Middleare and started running into issues this morning and have now reproduced it to the below error:
POST https://www.linkedin.com/uas/oauth2/accessToken HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: www.linkedin.com
Cookie: bscookie="v=1&201504071234373bc02b47-9d08-477f-8375-b80b281ef416AQEptFjv8jXPI93YmF-H-3kvnwSLwBF8"; bcookie="v=2&46f6f299-6702-48bf-8634-7ba023bd5099"; lidc="b=LB23:g=218:u=215:i=1428412320:t=1428487523:s=AQEQQq6vlEKPT3LW8c0cPEzRTKp-ToxL"
Content-Length: 267
Expect: 100-continue
Connection: Keep-Alive
grant_type=authorization_code&code=AQQRSgEH8vczSFJKNxtMpunzjYN6YJxoF2hiX_d9RVkqBvMC7TzRpur0p9NJFdQOUNf8RmFyj_cCg3ENTucRw5e-gQfEZ5sPGoujiFRsQ8Tb0pLnaog&redirect_uri=http%3A%2F%2Flocalhost%3A1729%2Fsignin-linkedin&client_id=&client_secret=
Results in method not found.
HTTP/1.1 405 Method Not Allowed
Date: Tue, 07 Apr 2015 13:13:16 GMT
Content-Type: text/html
Content-Language: en
Content-Length: 5487
X-Li-Fabric: PROD-ELA4
Strict-Transport-Security: max-age=0
Set-Cookie: lidc="b=LB23:g=218:u=215:i=1428412396:t=1428487523:s=AQExeP2uX-7KXQv79NIZmW0LB09uE4eJ"; Expires=Wed, 08 Apr 2015 10:05:23 GMT; domain=.linkedin.com; Path=/
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache, no-store
Connection: keep-alive
X-Li-Pop: PROD-IDB2
X-LI-UUID: 0FM/jIG90hPAzyhAqCsAAA==
Looking for anyone to confirm that there was a change on linkedin causing this error and that its not application specific.
Note that i removed teh above clientid/secrets.
I also spent most of the morning off and on trying to get this to work. Frustratingly it worked fine using Advanced Rest Client chrome tool. A combination of this and fiddler showed the only difference in the header was that Expect: 100-continue flag in the header. The only way I was able to get it to be set to false was in the web.config section
<system.net>
<settings>
<servicePointManager expect100Continue="false" />
</settings>
</system.net>
Hope this helps.
I ran into this issue this morning too (I'm using DotNetOpenAuth). It looks like this is related to the use of the following request header: Expect: 100-continue
After removing this request header, the HTTP/1.1 405 Method Not Allowed response no longer occurs. Obviously this isn't much help if you don't have access to the source code!
I'm assuming this is due to a change in LinkedIn as I only started experiencing problems this morning. I'm guessing they'll need to look into a fix for this.
I started having this issue today. After some research about Expect: 100-continue I found that putting
System.Net.ServicePointManager.Expect100Continue = false;
in my Application_Start() function inside of Global.asax, takes out the 100-continue from the request and my login with LinkedIn is now working again.
Not a permanent fix as I would like to now why it broke in the first place.
I had same issue also use DotNetOpenAuth.
How I fix:
I remove from request header "Expect: 100-continue"
in my case redirect_uri was encoded and I remove encode for redirect_uri (for request to https://www.linkedin.com/uas/oauth2/accessToken )
For those using Owin Middleware and Owin.Security.Providers
A pre-release nuget was created with a fix.
https://www.nuget.org/packages/Owin.Security.Providers/1.17.0-pre
This works for now. But until we know what linkedin has changed or comes with statement about what they changed people can use this as a hotfix.
Alittle more background on the fix can be found at :
https://github.com/RockstarLabs/OwinOAuthProviders/issues/87#issuecomment-90838017
But the root cause is that LinkedIn changed something on there accessToken endpoint causing most of the libs using linkedin SSO had to apply a hotfix, but we yet haven't heard anything from linkedin.
Found a solution for curl, pretty simple:
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Expect:') );

Alfresco CMIS parents query returning unexpected empty result

Context
The CMIS parent operation allows one to get the full path(s) of an object from its id.
For instance, I give /alfresco/service/cmis/s/versionStore:version2Store/i/2f4cbf7a-0f8e-4fa1-81e5-8be69eb0532e and I get /Sites/swsdp/documentLibrary/Presentations.
I have an Alfresco Community 4.2.e server.
Not sure if relevant but it is purely out-of-the-box except I enabled ChangeLog:
audit.enabled=true
audit.alfresco-access.enabled=true
audit.cmischangelog.enabled=true
What occurs
When I run a "parent" CMIS request below, I get the response below which contains zero Atom entries:
GET /alfresco/service/cmis/s/versionStore:version2Store/i/2f4cbf7a-0f8e-4fa1-81e5-8be69eb0532e/parents?includeAllowableActions=false&includeRelationships=none&includeRelativePathSegment=true HTTP/1.1
User-Agent: Apache Chemistry DotCMIS
Authorization: Basic YWRtaW46YWRtaW4=
Host: 192.168.0.66:8080
Connection: Keep-Alive
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
Content-Type: application/atom+xml; type=feed;charset=UTF-8
Transfer-Encoding: chunked
Date: Thu, 06 Mar 2014 06:57:46 GMT
477
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:app="http://www.w3.org/2007/app" xmlns:cmisra="http://docs.oasis-open.org/ns/cmis/restatom/200908/" xmlns:cmis="http://docs.oasis-open.org/ns/cmis/core/200908/" xmlns:alf="http://www.alfresco.org" xmlns:opensearch="http://a9.com/-/spec/opensearch/1.1/">
<author><name>admin</name></author>
<generator version="4.2.0 (r56674-b4848)">Alfresco (Community)</generator>
<icon>http://192.168.0.66:8080/alfresco/images/logo/AlfrescoLogo16.ico</icon>
<id>urn:uuid:2f4cbf7a-0f8e-4fa1-81e5-8be69eb0532e-parents</id>
<link rel="service" href="http://192.168.0.66:8080/alfresco/service/cmis"/>
<link rel="self" href="http://192.168.0.66:8080/alfresco/service/cmis/s/versionStore:version2Store/i/2f4cbf7a-0f8e-4fa1-81e5-8be69eb0532e/parents?includeAllowableActions=false&includeRelationships=none&includeRelativePathSegment=true"/>
<link rel="via" href="http://192.168.0.66:8080/alfresco/service/cmis/s/versionStore:version2Store/i/2f4cbf7a-0f8e-4fa1-81e5-8be69eb0532e"/>
<title>text1.txt Parents</title>
<updated>2014-03-05T16:32:44.359+09:00</updated>
</feed>
0
What I think should occur
For reference, the CMIS standard has an example request/response for parents.
The example response contains an Atom entry which has the path I am looking for:
<atom:entry>
[...]
<cmisra:object xmlns:ns3="http://docs.oasis-open.org/ns/cmis/messaging/200908/">
<cmis:properties>
[...]
<cmis:propertyString queryName="cmis:path" displayName="Path" localName="cmis:path" propertyDefinitionId="cmis:path">
<cmis:value>/My_Folder-0-0/MultifiledFolder1</cmis:value>
Question
Why is Alfresco not giving me any Atom entry?
What is wrong with my request? I am pretty sure the id refers correctly to the existing file /Sites/swsdp/documentLibrary/Presentations/test1.txt.
You are using a deprecated CMIS endpoint with an outdated CMIS implementation.
Try:
http://<host>/alfresco/api/-default-/public/cmis/versions/1.0/atom

asp.net web service return invalid XML

i have a web service its run locally, but when i hosted on AWS its not running from my client I get the error "System.ServiceModel.ProtocolException: There is a problem with the XML ..."
I tried to call it from SoapUI its working
this is the request :
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:her="http://HerakiNet.com/">
<soapenv:Header/>
<soapenv:Body>
<her:SayHello>
<!--Optional:-->
<her:name>Ahmed</her:name>
</her:SayHello>
</soapenv:Body>
</soapenv:Envelope>
and the response as raw:
HTTP/1.0 200 OK
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Date: Sun, 29 Dec 2013 11:12:39 GMT
Server: Microsoft-IIS/8.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Content-Length: 359
X-Cache: MISS from UB15-WMJ-080811
Via: 1.1 UB15-WMJ-080811:3128 (Lusca)
Connection: keep-alive
<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><SayHelloResponse xmlns="http://HerakiNet.com/"><SayHelloResult>Hello , Ahmed</SayHelloResult></SayHelloResponse></soap:Body></soap:Envelope>
can any one help??
this is the result of executing a small test from DotNet App:
System.ServiceModel.ProtocolException: There is a problem with the XML that was
received from the network. See inner exception for more details. ---> System.Xml
.XmlException: The data at the root level is invalid. Line 1, position 1 ...
the application code is:
var client = new EstimatorWcfService.EstimatorWebServiceSoapClient();
Console.WriteLine(client.SayHello("Ahmed"));
According to error, you are calling wrong end point url from your client.
There would be two urls in service tag in your wsdl one for http and another for https. May be you are using https one instead of http. Cross check from soap ui (at top of your request).

Is the version of HTTP either 1.0 or 1.1 defined by webserver? How works the HTTP protocol definition?

I have a quick question but in advance I've read the RFC 2616 Chapter 14.22 about Host and HTTP Header but I still not understand where in httpd.conf or configuration file of a webserver should be changed? Please correct me if I'm wrong.
Look at following two HTTP GET I did to an Apache. The first one is GET for HTTP 1.0 , the other one is GET for HTTP 1.1. See the output:
HTTP/1.0 200 OK
Date: Thu, 24 Oct 2013 03:46:22 GMT
Server: Apache/1.3.41 (Unix) mod_gzip/1.3.26.1a PHP/5.2.9 mod_throttle/3.1.2 mod_psoft_traffic/0.2 mod_ssl/2.8.31 OpenSSL/0.9.8b
Vary: *
Last-Modified: Fri, 10 Aug 2012 20:22:30 GMT
ETag: "17c815b-3b-50256d86"
Accept-Ranges: bytes
Content-Length: 59
Connection: close
Content-Type: text/html
<html>
<body>
<center>webli7</center>
</body>
</html>
HTTP/1.1 400 Bad Request
Date: Thu, 24 Oct 2013 04:04:40 GMT
Server: Apache/1.3.41 (Unix) mod_gzip/1.3.26.1a PHP/5.2.9 mod_throttle/3.1.2 mod_psoft_traffic/0.2 mod_ssl/2.8.31 OpenSSL/0.9.8b
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
16e
The HTTP protocol version is decided dynamicaly, not through configuration files. The client send a request specifying the highest protocol version that its support. Then, the server must respond with either the version requested by the client, or any earlier version that it prefers.
Since Apache does support HTTP/1.1, it should therefore match exactly the version provided by the client.
There exist a flag that you may set in Apache's config to force Apache to use HTTP/1.0 in certain situations, even though the browser requested HTTP/1.1. This is used to fix bugs in HTTP/1.1 handling of some very old browser. Today, you should not need to play with this flag.
As for your error, I would suggest that you make sure that your GET does provide the Host: header. This header is required in HTTP/1.1, yet optional in HTTP/1.0, and having it missing would certainly result in a 400 error.

Why won't Chrome or Safari properly play my MP3?

I have a web application running on Glassfish. The application is written in Java using Servlets.
The application allows you to upload files and get a direct link to that file.
For some reason, Safari and Chrome (possibly other browsers) have issues playing MP3 files (and other audio/video files) uploaded to this application.
An example uploaded MP3: http://uploads.graalcenter.org/upload/test.mp3
Sometimes, Safari will load the file and play it correctly, but most of the time it either stays on "Loading..." forever, or starts playing for a few seconds and then stops downloading it.
My browser is sending these request headers:
GET http://uploads.graalcenter.org/upload/test.mp3 HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7) AppleWebKit/535.1+ (KHTML, like Gecko) Version/5.1 Safari/534.48.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://uploads.graalcenter.org/info/test.mp3
Cache-Control: max-age=0
My server is responding with these response headers:
HTTP/1.1 200 OK
Date: Sun, 31 Jul 2011 02:02:03 GMT
X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.2-b06 Java/Sun Microsystems Inc./1.6)
Content-Length: 1137602
Server: GlassFish Server Open Source Edition 3.2-b06
Content-Type: audio/mpeg
Accept-Ranges: none
For comparison, I have uploaded the same file to an Apache server here.
The server responds with these headers:
HTTP/1.1 200 OK
Date: Sun, 31 Jul 2011 02:06:56 GMT
Connection: Keep-Alive
Content-Length: 1137602
Last-Modified: Sun, 31 Jul 2011 02:05:57 GMT
Server: Apache
Etag: "1aa08001-115bc2-4a953f48b6b40"
Content-Type: audio/mpeg
Accept-Ranges: bytes
Keep-Alive: timeout=2, max=100
The file plays correctly.
The only difference I can see is that my application does not accept range requests, but this shouldn't cause any issues, should it?
If I download the MP3 from my web application via curl, it has the same MD5 hash, so it's not corrupting the MP3 in any way.
Does anybody have any idea what might be causing the MP3 to not play correctly?
It seems like the problem was AppleCoreMedia, the plugin which handles audio, doesn't work correctly when not using range data. I wouldn't make the leap of blaming it on Apple, as it's entirely possible I made some mistake, but I ended up implementing the HTTP Range header and the it now works every time.

Resources