3 ms·

Isn't that sort of what MHTML is? https://en.wikipedia.org/wiki/MHTML https://en.wikipedia.org/wiki/MHTML I remember saving .mht files with IE as a kid when w

Isn't that sort of what MHTML is? https://en.wikipedia.org/wiki/MHTML https://en.wikipedia.org/wiki/MHTML I remember saving .mht files with IE as a kid when working on assignments so I could disconnect the dialup and give my parents their phone line back :)

Already__Taken 8y ago
With service workers we're almost a save-as shim away from being back to this.
devwastaken 8y ago
Sort of, but mhtml isn't a good format. It was a hacky way of taking what emails did. It's embedding all content in a single file, not as an archive. Rather it should be you can open up the HTML archive like an actual archive and see the individual files.
- acqq 8y ago
  Opera 12 (the original one, before the managers decided that it should be based on Chromium) had the .zip files support built in; that means that if the URL was somepath/archive.zip/index.html and index.html refers to other files, they would be read from the same zip, even if they are only inside of the zip. I used it a lot for the local archives of the bigger content, it is amazingly convenient, and I'm sad that the same approach was not used anywhere else. It's not trivial to get it right, in the security aspects (the zip implementation has to be robust, the url handling too) but it's doable and it would be very practical to have it. Tangentially, the good thing of the zip format is that it has so called "central directory" which means that you don't even have to load the whole archive if not all data is needed, just the last part of the file, and from there you get the offset and the location of the needed file. So the Zip files could work beautifully with the https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ra... when they are huge(1). The small ones are most effective to be downloaded at once, of course. 1) I've actually done such a sequence by hand a few times when I had a slow internet and knew that I don't need the whole zip file, but just to see that all files are inside: I've made the range request for the end of the file which would be enough for the estimated number of files inside, and so I've had the list of all the files in the archive without needed to download the whole archive: I've reconstructed the same file size but left the rest of it be zeroes, and some of the zip tools I've used treated the archive directory exactly as I needed it.
  - devwastaken 8y ago
    The reason I don't suggest zip is due to it's insecurity, like zip bombing. Itd be better for archival if we just had tar, and then sometime lightweight on top of it if compression is wanted. That way you could have js generate the archive client side. It is interesting how the older web got some things right, though, and now it's 2018 and those ideas one would think should be robust by now, isn't even there.
    - acqq 8y ago
      Zip is not inherently insecure anymore than any other URL parsing and archive handling is. Technically it's many orders of magnitude better solution for the random access (due to the existence of the central directory as I've already mentioned) than tar-gz, if it's done right. Out of every archive format a pathological case can be constructed, just like it can from the relative file names etc, but such attempts can be simply rejected during the processing once some thresholds are reached. The original article demonstrates that JPG reading implementation can be bad enough, and the same can be said for every format, even text based. It simply has to be done right (including fuzzing at the end).

Already__Taken 8y ago

With service workers we're almost a save-as shim away from being back to this.

devwastaken 8y ago

Sort of, but mhtml isn't a good format. It was a hacky way of taking what emails did. It's embedding all content in a single file, not as an archive. Rather it should be you can open up the HTML archive like an actual archive and see the individual files.

acqq 8y ago
Opera 12 (the original one, before the managers decided that it should be based on Chromium) had the .zip files support built in; that means that if the URL was somepath/archive.zip/index.html and index.html refers to other files, they would be read from the same zip, even if they are only inside of the zip. I used it a lot for the local archives of the bigger content, it is amazingly convenient, and I'm sad that the same approach was not used anywhere else. It's not trivial to get it right, in the security aspects (the zip implementation has to be robust, the url handling too) but it's doable and it would be very practical to have it. Tangentially, the good thing of the zip format is that it has so called "central directory" which means that you don't even have to load the whole archive if not all data is needed, just the last part of the file, and from there you get the offset and the location of the needed file. So the Zip files could work beautifully with the https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ra... when they are huge(1). The small ones are most effective to be downloaded at once, of course. 1) I've actually done such a sequence by hand a few times when I had a slow internet and knew that I don't need the whole zip file, but just to see that all files are inside: I've made the range request for the end of the file which would be enough for the estimated number of files inside, and so I've had the list of all the files in the archive without needed to download the whole archive: I've reconstructed the same file size but left the rest of it be zeroes, and some of the zip tools I've used treated the archive directory exactly as I needed it.
- devwastaken 8y ago
  The reason I don't suggest zip is due to it's insecurity, like zip bombing. Itd be better for archival if we just had tar, and then sometime lightweight on top of it if compression is wanted. That way you could have js generate the archive client side. It is interesting how the older web got some things right, though, and now it's 2018 and those ideas one would think should be robust by now, isn't even there.
  - acqq 8y ago
    Zip is not inherently insecure anymore than any other URL parsing and archive handling is. Technically it's many orders of magnitude better solution for the random access (due to the existence of the central directory as I've already mentioned) than tar-gz, if it's done right. Out of every archive format a pathological case can be constructed, just like it can from the relative file names etc, but such attempts can be simply rejected during the processing once some thresholds are reached. The original article demonstrates that JPG reading implementation can be bad enough, and the same can be said for every format, even text based. It simply has to be done right (including fuzzing at the end).