I have created a webapplication and set up an endpoint which returns a FileStreamResult, these can be large zip and pdf files for example. The main issue I'm facing is that if a download gets interrupted (for example the internet goes down by the client), the temporary file that is generated by the browser is immediately deleted.
I'm aware of range-requests, but to utilize them, I would have to read files from the client, to determine how much progress the download made, which is not possible from the server side and also, the same problem persists about the temporary file deletion.
So this seems like a browser limitation to me, but please correct me if I'm wrong, I would appreaciate any ideas.
Related
I have a FileSystemWatcher that is supposed to process incomming files (on an IIS server, in ASP.NET Core) and after processing these, move them to another destination.
It works like a charm, but only when there are users connected to the website, I was wondering what causes this kind of behaviour.
Extra info: When a file pops up in the directory it is listening to and there is no user connected to the website, the code that is defined in the Watcher_Created() method is not executed, and when processing multiple files, upon disctonnection the other files are no longer beeing processed.
Kind regards
Solution found here:
I hope it helps others.
https://thycotic.force.com/support/s/article/Changing-IIS-to-not-stop-worker-process-in-IIS-7-and-8
Using MS Edge and apache w/ php, I just discovered via access.log that when I have the JavaScript debug panel (i.e. developer panel) open, it is making every http call twice. When I closed this panel, it has fixed the issue of all insert statements getting called twice.
Question: Does this doubling of http calls happen on every / most browsers that I need to look out for, or is this something special/unique with MS Edge?
I can't speak for all browsers and all developer tools. But, for IE and Edge the first time you open the tools and then open a JS file in the sources view it will try to request the file again. That request will be served from the local browser cache, sometimes not, depending on the cache settings for the file being requested.
The reason browser tools need to make this request is that browsers will often throw out the original source file as it doesn't need it to execute the page, as the source has been parsed it into something else that it can work with.
However, after you've opened the developer tools the browser will keep around sources in future navigations, either in the tools front end or elsewhere. Not keeping sources is an optimization for the first time use case, to save browsers keeping around source on the very low odds of the tool being used on any given navigation.
Of course some files are never cached by the browser and will need to be downloaded when requested by the tools, for example sourcemapped files.
In general any resources on your site that can be accessed by HTTP GET should be idempotent. That is, a GET shouldn't change the resource being requested (or generall the state of your site), so hopefully making additional requests shouldn't be an issue.
Prior to migrating from Mobile to App Services I could change node.js APIs in real time. Now changes seem to take an undetermined time to go live. I don't know if they're now being compiled or cached anywhere along the way. Ideally I would like to regain the ability to effect immediate change.
Technically, there is a file watcher that watches a subset of the files in your site - when you change one of those files, the site is meant to restart, thus making your change go live. This is configured in the web.config file which is a part of your site.
Make sure that the web.config is configured to watch the files you are interested in.
Restarting the site manually is a backup step that is effective.
We have some users who are using Adobe Acrobat to edit .pdf files over WebDAV. There are a couple of issues that we are experiencing.
The acrobat client seems to be very chatty. We get multiple PROPFIND calls before the first GET. To edit even the simplest pdf takes ~11 secs. due to all these calls which includes PROPFINDS & OPTIONS, a LOCK, GET, PUT, UNLOCK and frequently a pair of MOVE/DELETE commands.
When the user eventually saves then closes the document and immediately reopens the document, their changes to not appear to have saved. If they wait for about 30 seconds (possibly less) before they reopen the document the changes do show up so there appears to be some type of caching going on, but our website (asp.net) has output caching turned off.
Sometimes the users get an error of 109 saying the document could not be saved. This appears to be coming from Adobe Acrobat because we don't see errors in the log, however it could be related to #1 above where the MOVE/DELETE has been issued and enough time has not passed.
My questions are therefore
Have you tested/used Acrobat for editing pdfs?
If so did you have these issues?
Is there a setting in the WebDAV engine that allows you to turn caching off or does it use the underlying IIS settings?
I guess you are using Microsoft Mini-redirector driver (Windows Shell, WebDAV client provided with Windows) to open and edit documents.
This is a Mini-redirector specifics, sometimes it traverses folders and submits other unnecessary requests.
Regarding performance. This may be caused by proxy settings. Please see "Long Delays When Connecting and Browsing WebDAV Server" section here.
This is typically caused by Mini-redirector cache. As far as I know there is no any documentation about how to disable cache in Mini-redirector. There is no real solution for this, you just need to wait for some time until the client cache invalidates.
The server Engine itself does not have any caching options. It just processes the WebDAV request and generates response. It also independent of hosting environment and its settings, such as IIS, HttpListener, etc.
Please examine the WebDAV log file WebDAVLog.txt. By default it is located in \App_Data\WebDAV\Logs. Are there any exceptions in it?
We have an Adobe AIR application which could be possibly downloaded from multiple domains. And when it's run, it should connect back to the site it was downloaded from to get data to show to the user.
So far we have a separate application build for each domain with a site URL hardcoded into it. And I wonder is there a way for AIR application to find out at runtime the URL (or at least domain) from which it was downloaded?
What we would like to have is a single downloadable binary served from all different domains, which still can know it's origin URL.
There's no function to retrieve such information, it would just make no sense if you think about it.
The most stable way is to include an external configuration file into the package.
Note that you can use ANT to automate this process for this final deployment.
There's no direct way to do it.
Here are some options which come in mind:
Build different versions for each site (this could be automated)
Let user choose the site at first launch
Try to guess it using using whatever resources you have (timezone, language, etc)
How should this work? The only solution i see (independent from AIR) is that you deliver an extra (properties) file with the application, containing the URL downloaded from. So you dont need to build a separate app for each domain, but only package a different domain-file with it. The app then reads this file and executes some context sensitive stuff.
I am trying to address the exact same issue right now.
It looks like you can modify the install badge to pass parameters to the air app.
From what I gather the values are only passed down on install or launch-from-badge.
Something I plan on researching is that one of the parameters in "AIRBadge.as" is _appURL which is the URL of the page the badge is on. I don't yet know if that value makes it down to the installed AIR app in some way; but it could be a useful property. I'm ultimately hoping that the AIR install process injects that into the application descriptor xml, but I'm not holding my breath.
Check this page out: http://archive.davidtucker.net/2008/01/10/air-tip-5-passing-arguments-to-an-application-on-install/#
When the user downloads, you could store their IP address in your central DB. Then when the app is installed and runs the first time, the app could hit your central DB to match up their IP address with the server they downloaded from.
A cookie with a specific name being stored on a download page, and the AIR app looking for that? Though that might not work for direct downloads. It might also be hard to pull off since knowing the specific browser used to download it would be an issue.