I have found an issue on our SharePoint 2013 farm where files >50MB in size cannot be uploaded to a document library using Chrome. The same files in IE10 upload without a problem.
When uploading, we receive the following error:
"Sorry, something went wrong
An unexpected error has occurred."
In ULS we can see the following:
Application error when access /xxx/xxxxxxx/_layouts/15/UploadEx.aspx,
Error=Maximum request length exceeded.
at System.Web.HttpRequest.GetEntireRawContent()
at System.Web.HttpRequest.GetMultipartContent()
at System.Web.HttpRequest.FillInFormCollection()
at System.Web.HttpRequest.EnsureForm()
at System.Web.HttpRequest.get_Form()
at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.IsSignInResponse(HttpRequest request)
at Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModule.IsSignInResponse(HttpRequest request)
at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.CanReadSignInResponse(HttpRequest request, Boolean onPage)
at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
at Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs eventArgs)
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
We have checked the following and have been left scratching our heads:
The maximum upload size has been set in the Web Application to 2GB
The 2GB limit is reflected in the web.config file
It affects all document types we have tested
We have tested against multiple users, on multiple machines against multiple site collections
Files less than 50MB will upload through Chrome as expected
IE will upload the same file without error
Due to the number of users, at the moment it would require a pretty good business case to move everyone to a later version of Chrome. Due to this I was wondering if anyone might have any thoughts?
Many Thanks,
Adrian
OK, so finally found an answer to this, and it is a bug within Chrome v27.
On a test machine we upgraded to version 28 and the uploads proceeded as expected without any further amendments.
Unable to find anything online to document this however, it appears as though it is resolved by a Chrome update.
Related
I am trying to serve PDF files from a bucket on Amazon-S3, using PDF.js in the browser. I have amended the relevant CORS policy in S3. However, I am receiving the following error message in the browser:
PDF.js v2.2.71 (build: 80135378)
Message: file origin does not match viewer's
After a search, I have found several related questions, such as this question here, as this appears to be a relatively common issue. It is fairly obvious therefore that I need to allow Amazon S3 as a host origin. Therefore, I amend my viewer.js file to include the host, like so:
var HOSTED_VIEWER_ORIGINS = ['null',
'http://mozilla.github.io',
'https://mozilla.github.io',
'https://thepdfbucket.s3.eu-west-
2.amazonaws.com'];
However, if I do a hard reload and inspect sources, I can see that the error is thrown in webpack:///web/app.js:
Uncaught (in promise) Error: file origin does not match viewer's
at validateFileURL (app.js:1482)
at webViewerInitialized (app.js:1541)
If I examine app.js, I can see the HOSTED_VIEWER_ORIGINS array, mapped from the viewer.js file. However, it does not include the amended array, i.e. my addition of https://thepdfbucket.s3.eu-west-2.amazonaws.com.
I cannot get this to work. I believe I probably have a cache issue, however, I have cleared all the browser's cache, I have even built PDF.js again from github and tried to amend the viewer.js file, prior to compilation.
If I have amended the viewer.js file, and app.js is mapped from viewer.js, but it does not reflect the recent changes, my conclusion is that it must be using a cached file. How do I clear this cache, and get app.js to reflect the changes I have made?
I really would appreciate any help here, as I've spent the whole of yesterday on this issue, and I cannot get my head around how this all fits together.
Many Thanks.
I also ran into this problem and investigated.
Version of PDF.js: pdfjs-3.3.122
The reason is that when debugging in the browser, the debug information is from viewer.js.map and not the actual working viewer.js source code.
The quickest way to debug is to delete viewer.js.map.
Perhaps the reason for the error is a mis-specified value.
That was the case for me.
Incorrect: https://google.com/
Correct: https://google.com
Translated with www.DeepL.com/Translator (free version)
Sometimes I get an error "ERR_CONNECTION_CLOSED" for my application https://coach5.isxapps.com/ and the wired thing is that it only happen with google chrome and that too randomly.
It am not getting this error with Firefox or IE, Systems are scanned for any kind of viruses, spywares, malwares (no add-ons/extensions are installed on browser)
Attached are the screen-shots and net-internal json log files.
Any kind of help will be highly appreciated.
I'm writing an MonoTouch app that downloads over 1000 individual PDF files and open them as one giant pdf file. I have no problem viewing the document but if I keep close/open the document few times it will throw
EXCEPTION: Too many open files
t System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00275] in /Developer/MonoTouch/Source/mono/mcs/class/corlib/System.IO/FileStream.cs:310
at System.IO.FileStream..ctor (System.String path, FileMode mode) [0x00000] in :0
I've been using MonoTouch for a couple years now and have not had any issues like this. Could this be a new Xamarin.iOS issue?
I also saw in the forum they fixed this issue by using ulimit -a but how do I apply that to an iPad app?
Anyone?
There's no limit on open files inside Xamarin.iOS itself. However this exception will be thrown when the operating system (iOS in this case) reports too many files are open.
Check your device logs (e.g. Xcode organizer) and you should see iOS complains about the number of opened files.
When dealing with files, even more than other IDisposable, it's important to close them when you no longer require them. IOW do not wait for the GC to automagically do it.
Also you might want to try using Instruments or something like
this to see which files are open - that
should hint you about who opened them. E.g. they might not all be yours (e.g. if you embed many fonts inside your application).
I am trying to store a mp4 video file (rather small ~ 2.5MB) in the local app cache.
Manifest looks like:
CACHE MANIFEST
viddy.mp4
Chrome (22.0.1229.94 m) will log the following in the console:
Creating Application Cache with manifest http://example.net/cache.manifest
Application Cache Checking event
Application Cache Downloading event
Application Cache Progress event (0 of 1) http://example.net/viddy.mp4
Application Cache Error event: Resource fetch failed (-1) http://example.net/viddy.mp4
When I click the link right next to the Error it's opening the file quite fine.
My manifest is served with the correct MIME-type (I'm using the HTML5 Boilerplate .htaccess-file) and the video is served Content-Type:video/mp4
Is my file too big? I am perfectly able to cache a 1MB image this way, so I thought filesize should not be a problem? Safari on desktop and iPad does cache the video just fine.
Remark: I have seen this question but it does not cover my problem as the solution seemed to be something Python-related.
Chrome does not allow data to be stored in Incognito Mode.
I experienced similar problem and this is how I solve it. In this case Chrome does not give any helpful information about error. I've tried to load same page in Safari (Mac, but Windows should work as well), and I got description, that response for specified resource returns 302 (Redirect) and HTML5 Application Cache cannot handle it.
In your case it might be the same, but I'd suggest you to enable the sniffer and see, what response you get from your resource. If it's different than 200 - you figured the issue.
P.S. I've cached files up to 32 MB without any problems.
I have a chrome extension with an existing extension Id and a local update file (on our server) that is used by many users.
I uploaded the extension to the extension store successfully.
Seeing I needed to make some changes I deleted the extension from the store.
I made the required changes and tried to upload the amended extension file again (with the same id). I got the error: ""An error occurred: Gallery system error, please try again later."
I read in some forums that I should wait. I'ved tried a few times and it almost 2 weeks since my first uplaod and I still cannot upload my new extension.
How can I resolve this?
Is there something that can be done to resolve this issue?
Chrome Web Store does not allow duplicate upload even after deletion, we reserve the ID forever, however we do not have clear message indicating this so people delete item casually, we have improved the message. This has become a common problem as Chrome M21 forbids apps installation from outside of CWS, we should communicate this better.
If you have strong reason to need the item id back (such as you have already been distributing the item under the ID for a long time), please post your item ID and CWS account email at http://code.google.com/p/chromium/issues/detail?id=138706 and we can try do a manual recover for you as an exception.
Sorry for this inconvenience.