Trying to open an attachment with this url and it doesn't work. Any idea why?
https://Blah-apps.com/Development/StrongB.nsf/0/(Attach)/0/B3B9D4480BEF667C852588310078E1AE/$File/golf.pdf!%20&OpenElement
Thanks for any ideas
The attachment was originally created on the web and was an embedded object. I then wrote code to move it to a Rich Text Field and that didn't help. The error I get is
HTTP Web Server: Couldn't find design note
This is from a note that I pulled together for HCL some time ago listing the issues we had with Domino 11 having upgraded from 9. This might help although it is not clear what version you are on.
Broken Download links for LZ1 compressed attachments. - CS0313452
After upgrading to FP5 customers found that they could not download some attachments.
We were able to reproduce this issue 100% and provided HCL with a database.
https://eon.focul.net/eon/apps/moc.nsf/xp_f_mod.xsp?action=openDocument&documentId=67BC79B86B06BAFD802582B30042ACFB FoCul determined that this happens to attachments that are automatically compressed with LZ1 even when the database settings do not enable compression.
+SPR# GRHEBVYNW7 - Server - DAOS - Fixed an issue where after upgrading to 11.x,
running dbmt -c on DAOS enabled databases results in duplicate DAOS objects being stored.
This regression was introduced in 11.0.
The URL syntax affected is the old style https://<>//<>/<database.nsf>>/<>/$FILE/<>.jpg
whereas the newer “XPage”style syntax works fine
We modified our applications to use the XPages style syntax as a good work around.
This is the XPages url style
https://acme.focul.net/apps/moc.nsf/xp_f_mod.xsp?action=openDocument&documentId=67BC79B86B06BAFD802582B30042ACFB
Your use of /0/(Attach)/0 looks wrong. Try this format instead: http://host/Database/View/Document/$File/Filename?OpenElement (source: https://help.hcltechsw.com/dom_designer/9.0.1/appdev/H_ABOUT_URL_COMMANDS_FOR_OPENING_IMAGE_FILES_ATTACHMENTS_AND_OLE_OBJECTS.html)
So in your case:
https://blah-apps.com/Development/StrongB.nsf/0/B3B9D4480BEF667C852588310078E1AE/$File/golf.pdf?OpenElement
I'm migrating from PHP 5+ to PHP 7+ on standard app engine.
To upload file, I'm making a POST request to an internal endpoint with all form data (text and file to upload).
Actually what I was doing on v5 to let this work:
Get the URL with CloudStorageTools::createUploadUrl
POST everything to the url returned from the step before
In this way, all posted form (text and file to upload) was posted correctly to my internal endpoint and file can be uploaded on google storage.
Migrating to php 7+ CloudStorageTools::createUploadUrl can't be used.
Direcly upload working fine, if file is not so bigger.
For bigger file I haven't still found a solution, a lot of people have this problem but seems no one actually solved it.
There is some workaround or some tips to solve it?
I've already tested different methods got from here: https://googleapis.github.io/google-cloud-php/#/docs/cloud-storage/v1.23.2/storage/readme
No one is actually working (I got URL where upload, but at the end of upload everything crash).
Google documentation about that is not so clear, they say you can't use the older library, but actually online I can find always the same basically code that it's not good for larger file.
I have a Vue.js website with a PDF file which is included in my ultimate javascript bundle via webpack. (It's my CV.) The following build and delivery process has worked perfectly fine for me since 2017, but suddenly stopped working in iOS 14:
Build the PDF with LaTeX.
Use webpack's url-loader to include the PDF in my webpack bundle as a base64 data URI.
Load that URL into a vuex data store, and then just deliver it as a link when clicked.
For the last three years, this has worked fine: I've been able to click on the link and get a working PDF. It's been kind of random and platform-specific whether the PDF opens in-browser or shows up in a download folder, and whether it gets the filename I've asked it to get or not, but, well, that doesn't matter to me. And the core functionality of click the link and get the PDF has worked on every browser and every platform I've ever tried it on.
All of a sudden, with iOS 14, it's stopped working. Now, when I try to activate the PDF link in iOS Safari, nothing happens at all. When I do it in iOS Chrome, it produces a little popup claiming it downloaded a document, but nothing seems to actually be able to open the document. And when I do it in iOS DuckDuckGo, it just displays the base64 data URI in the address bar.
Interestingly, if I take the dataURI that DDG displays in the address bar and copy and paste it into Safari or Chrome on iOS, it actually displays my pdf. So the browsers still have the capacity to display a PDF from a data URI. It just doesn't want to do so from my link.
And my site still works as expected on the desktop. Including in Safari on the desktop. Also, it still works on my wife's phone (she's still on iOS 13). So this is clearly something Apple changed in iOS 14. But what? And how to get my site working again?
I'm guessing that Apple has changed the behavior of the renderer in iOS in some fashion to cause it to break across browsers but nowhere else (since browsers in iOS are all still required to rely on webkit, right?)
This is a pretty important feature to me. I made this decision deliberately for perceived performance---combined with pre-rendering, everything on my site, including the PDF, loads very close to instantly from the user perspective. So I'd really like to keep it.
I'm using Webpack 2.6.1 and Vue 2.3.3. This is a stable build that has been working flawlessly for three years, so I haven't felt the need to update anything except for security updates.
After searching around, I did find this Apple dev discussion which suggests that in iOS 14, Apple newly blocks redirects to data URIs. But I'm not doing a redirect, I'm actually navigating directly to the URI through a link. And the linked discussion suggests that the newly banned behavior just brings Apple in line with what other browsers already ban---but my code works in every other browser, so that can't be it.
Relevant code, to the extent it matters (though it's so basic and obvious that I doubt a simple code fix will be the answer here):
from my webpack.base.js:
{
test: /\.(pdf)$/,
loader: 'url-loader'
},
from my vuex store, in state.js
import cvURL from './assets/pdf/gowdercv.pdf';
from the component containing the link that points to PDF:
<p><a :href="cvURL" download="gowdercv.pdf"><img src="../../assets/icons/file-pdf.svg" class="cvicon"> Download in PDF</a></p>
which is loaded as a computed property to the component, i.e.,
computed: {
cvURL: function(){return this.$store.state.cvURL;},
Does anyone know how to get functionality back in iOS? Is there a workaround built in recent versions of webpack or vue for this? Thanks!
Update: after some help off SO, an acquaintance turned up this similar problem, which also came up with a solution: turning the base64 URI into a blob and passing that data url. Which also solves my problem. Though that SO doesn't have an accepted answer, so I can't vote to close my own question as a duplicate, alas.
I have been fiddling with rails apps for a while and I sometimes see this behavior on Safari (could be on other browsers as well, not sure) where the browser downloads the response as a file instead of rendering it in the browser. I wonder why that is.
The last time it happened made me decide to ask on stack overflow. My current setup is a very basic rails app that implements devise and I get a file named 'sign_in.admin' with just the following content:
You need to sign in or sign up before continuing.
I know that string comes from the devise locale and is supposed to be rendered with a layout, but the browser just downloads it as a file as if I chose to 'Download linked file as...' It's happened to me before where instead of rails routing me somewhere it downloads a file. Can somebody explain why my browser sometimes does that? I have all the latest updates.
We built a PWA with Ionic 3, which is a multiple page application. We host this on a linux server with nginx and use Laravel as a backend
The situation
We have seen that a update to a PWA is not always instantly, our client requested that if we released a update this would happen instantly and automatically.
What we tried
File based caching:
Our first thought was to use the concept of (old fashioned?) cache busting, so when building the app we use a random hash string in the filename. This ended up causing a major issue: Some PWA’s seem to hold on to the old index.html. In our access log we can see that old files get requested. The result being people will see a white screen after the splash screen. The only way for them to fix it is to reinstall the PWA completely.
Url based caching:
We devised a new plan: instead of using random hash string in the filename we moved in to the folder name. The request path would look like this: ./build/98312uj91eh9u2e/vendor.js. With NGINX we remove the hash and serve the same file, so it will return the the file from this path: ./build/vendor.js. This caused another issue where files would be mismatched. So some user would have parts of the old version and parts of the news versions which caused a lot of random issues.
Hosting multiple versions hoping they would update:
This pretty much did nothing other than creating lot of confusion. because some PWA’s would never update some people would be stuck on a old version and not see the new features.
Our current idea
Instead of using a static html file we are thinking of using javascript to make an API call to the backend of the PWA. Which will return a string with the current version of the PWA. This version will be the random string contain within the file names. This way, regardless of index.html updates, the content well be dynamic and not cause issue before description issues.
So what is the question?
Is it a good idea to make use of the concept where we would use JavaScript for making an API call or would this cause other issues we have not thought about yet.