Because the response from the API is PHP output, the usual `Content-Length` header is absent.
This [custom header technique](https://stackoverflow.com/questions/15097712/how-can-i-use-deflated-gzipped-content-with-an-xhr-onprogress-function/32799706#32799706) allows the client to know the total length of the data being received, in order to display a progress indicator.
Here's a code example with `XMLHttpRequest`:
```
xhr.addEventListener("progress", (e) => {
if (e.lengthComputable) {
onDownloadProgress({
loaded: e.loaded,
total: e.total,
});
} else {
const uncompressedContentLength = xhr.getResponseHeader(
"X-Uncompressed-Content-Length",
);
if (uncompressedContentLength) {
onDownloadProgress({
loaded: e.loaded,
total: Number(uncompressedContentLength),
});
}
}
});
```
Notes:
- `Fetch` can be used as well (only reason I use `XMLHttpRequest` is because `fetch` doesn't allow to track the progress of uploaded data (when creating a paste); whereas `XMLHttpRequest` does).
- `e.loaded` can be different between browsers; Firefox reports the length of the compressed data, Chrome reports the length of uncompressed data (see https://github.com/whatwg/xhr/issues/388). A workaround for this is to manually set our progress indicator to 100% when the request finishes.
This makes it possible to change the last part of the info text and
replace it with something individual. E.g pointing to the cmdline
client.
Signed-off-by: Andreas Schneider <asn@cryptomilk.org>
3 URLs of images used on social networks are passed in absolute URL.
Note that I did not pass all the images in absolute URLs, but, it could be consistent to do so, but, if the images work, maybe a relative call is more efficient?
Remove the version of PrivateBin, at the end of each image. This apparently prevents the opengraph from working, and, so I deleted on all of the images, to remain consistent at this level. This will make fewer requests, and, anyway, the images are not intended to change with each version.
