Transparent 7-Zip decompression
Closed this issue · 7 comments
According to the original documentation, MiniWeb has "transparent 7-zip decompression".
You can read about this in "/htdocs/index.htm". It says: "MiniWeb supports transparent 7-zip decompression. Web contents can be compressed into 7-zip archives and clients can access the contents inside the 7-zip archive just like in a directory."
But I can't find in your sources any library to support 7-zip. Do you have any idea on how to make this work? Have you tested this feature yet?...
By the way (off-topic), I can't successfully start the server on Windows XP (it runs without errors, but it doesn't work properly, since it doesn't resolve a proper "Interface" (host), like 127.0.0.1 or 192.168.0.105. The original release (by Stanley Huang), works just fine. But yours last release doesn't work correctly, at least on XP (I can show you some screenshots and command line arguments that I'm using, in case you need them).
– Leo
But I can't find in your sources any library to support 7-zip.
The sources (repository) are cloned from the original project. Apparently it was removed before I cloned, but thanks to version control, you can see it was removed by the original author at commit 15c8f0b .
I don't know exactly what these files are. Possibly some old LZMA SDK. Current LZMA SDK doesn't seem to have the APIs which the project uses when 7z is enabled (seemingly SzInit, SzUninit and SzExtractContent).
So I'd consider the documentation wrong.
Do you have any idea on how to make this work? Have you tested this feature yet?...
My guess would be that you need the files at 7zDec/ before commit 15c8f0b removed them, enable 7z for the build (probably just -D_7Z), and link with the the library which 7zDec/ compiles into.
No, I haven't tested nor tried to, because the files were removed for whatever reason.
I can't successfully start the server on Windows XP. it runs without errors, but it doesn't work properly, since it doesn't resolve a proper "Interface" (host), like 127.0.0.1 or 192.168.0.105 .
I just tried and it works fine for me on XP SP3.
Are you sure it's not blocked by the Windows firewall? How do you know it doesn't resolve a proper interface?
I haven't changed the default binding code (which should bind to address 0.0.0.0 i.e. all interfaces), but I did add an option -i to bind to a specific interface ( 078ed92 ), and I did change its display - which doesn't affect the binding ( 05d1204 ).
On XP SP3, I just tried miniweb -r . which worked for any interface: at the browser I tried: http://localhost or http://127.0.0.1 or http://10.0.2.15 (the last is the specific IP this machine happens to have) and all worked.
Then I tried miniweb -r . -i 10.0.2.15, and now localhost or 127.0.0.1 did not work, but 10.0.2.15 did work. I.e. completely as expected.
I can show you some screenshots and command line arguments ..
If you still have issues, sure. Preferably just copy-paste the command line, arguments and output as text (not screenshot), but screenshots would work too.
Note that I just pushed a change which tries to list the interfaces if we bind all of them (the default), instead of displaying "0.0.0.0". However, this is cosmetic (display-only) without any effect on the actual operation or binding of the server.
Also, for now I'm not uploading a new windows binary, so if you want this cosmetic feature, you'll have to build it yourself.
Are you sure it's not blocked by the Windows firewall?
Yes, sorry, it was my fault. The firewall was allowing the original miniweb.exe but denying the connection to your build (and hence, showing Error starting HTTP server). That was now solved, but it's still showing Host: 0.0.0.0:80. Nevertheless, the server is working fine.
Note that I just pushed a change which tries to list the interfaces if we bind all of them (the default), instead of displaying "0.0.0.0". However, this is cosmetic (display-only) without any effect on the actual operation or binding of the server.
Exactly, it's only a visual thing, since the server works correctly. And don't worry about the binaries, there is no hurry, I'll wait until you decide to release another revision/version in the future, along with another fixes.
You can mark this as solved if you want, unless you prefer to leave it open for a few days to wait for a reply from Stanley Huang (in case he finds and reads this thread). I will try to get in touch with him by email (to ask him why he removed that 7Zip feature or if there was a technical reason to do it).
And sorry for my late reply, I mostly have more spare time on weekends.
It's nice to see MiniWeb still alive. :)
Cheers,
Leo.-
The transparent 7z decompression is implemented in httphandler.c. Look for:
int uh7Zip(UrlHandlerParam* param)
@avih thanks for continuing my work!
@stanleyhuangyc thanks for the original miniweb! :)
To be honest, I don't have grand plans for it. I needed something small, and it fit the bill. I improved few things, and now that it works well enough for me. So that's about it...
As for 7z decompression, it is indeed at httphandler.c, but it needs the files at 7zDec/, which you removed at commit 15c8f0b .
Not that I mind much...
Anyway, I'll close this issue as "WONTFIX" for now, as I don't currently have plans to resurrect 7z support.