| Age | Commit message (Collapse) | Author | |
|---|---|---|---|
| 2024-08-24 | Merge remote-tracking branch 'origin/main' | UltraQbik | |
| 2024-08-24 | Don't compress what is already compressed | UltraQbik | |
| 2024-08-24 | Delete www/images directory | Qubik | |
| It takes space, and you could just check out the website itself Don't worry, when it will be closed, I will link them somewhere like google drive or even locally | |||
| 2024-08-24 | Add more info in projects | UltraQbik | |
| 2024-08-24 | *Proceeds to ignore SSL EOF Error* | UltraQbik | |
| 2024-08-24 | Sorry for that, png to webp | UltraQbik | |
| It's a 64x reduction of size, from 1 MiB to 16 KiB. I will still keep the .png files internally, as they are still better for compatibility and losslessness | |||
| 2024-08-24 | ignore ssl with EOF protocol violation | UltraQbik | |
| When a client decides to update a page a bunch of times, it sends this error to a server. There's nothing server can do about this | |||
| 2024-08-24 | zlib and gzip don't seem to work normally | UltraQbik | |
| 2024-08-24 | Remove response data stream requirement | UltraQbik | |
| 2024-08-24 | Add project page | UltraQbik | |
| 2024-08-24 | Change client handling | UltraQbik | |
| Previously _client_thread was checking for new data from client, which is very much useless, because the client will not send any data back twice. This commit removes the useless while loop that was there, as well as the thread that was started So currently, it's 1 thread per 1 request, which is how it should probably be | |||
| 2024-08-24 | More advanced path mapping | UltraQbik | |
| 2024-08-24 | Update styles | UltraQbik | |
| 2024-08-24 | Add HTML minimizer | UltraQbik | |
| 2024-08-24 | Move stuff in API | UltraQbik | |
| 2024-08-24 | Update to data streams | UltraQbik | |
| Instead of sending full files, and therefore storing them in ram (which is not always possible), send data in chunks of 64KiB | |||
| 2024-08-23 | Delete old code | UltraQbik | |
| 2024-08-23 | Merge pull request #2 from UltraQbik/threading-rewrite | Qubik | |
| Threading rewrite | |||
| 2024-08-23 | Remove some things | UltraQbik | |
| 2024-08-23 | remove timeout | UltraQbik | |
| Removed timeout because it interrupts client's downloads | |||
| 2024-08-23 | Update compression thing | UltraQbik | |
| 2024-08-23 | Update docs | UltraQbik | |
| 2024-08-23 | Update API and response class | UltraQbik | |
| 2024-08-23 | Update response class | UltraQbik | |
| 2024-08-23 | Update API | UltraQbik | |
| 2024-08-23 | remove useless code | UltraQbik | |
| 2024-08-23 | Working website (I think) | UltraQbik | |
| 2024-08-23 | Update API to give response | UltraQbik | |
| 2024-08-23 | Add thing to status code | UltraQbik | |
| 2024-08-23 | Add response | UltraQbik | |
| 2024-08-23 | Add request handler method | UltraQbik | |
| 2024-08-23 | Make restricted members | UltraQbik | |
| Make status codes immutable (I think that's how you do it?) | |||
| 2024-08-23 | Basic responses working | UltraQbik | |
| 2024-08-23 | Check received message length to prevent infinite loop in _recv_request method | UltraQbik | |
| 2024-08-23 | Add timeout to prevent client thread from running forever | UltraQbik | |
| 2024-08-23 | More graceful shutdown | UltraQbik | |
| There is a weird issue when a user tries to load a page, doesn't get a response (because that wasn't implemented yet), and when the webserver is attempted to be shutdown, it still tries to fetch user's request | |||
| 2024-08-23 | Add start method | UltraQbik | |
| 2024-08-23 | Add basic stuff | UltraQbik | |
| 2024-08-23 | Change path map a bit | UltraQbik | |
| 2024-08-23 | Add status codes | UltraQbik | |
| 2024-08-23 | Ditch asyncio, threading actually works much better | UltraQbik | |
| Problem was that I wanted to do things actually in parallel, and wanted to launch a task but without blocking the thread, asyncio was for whatever reason blocking the thread which was causing issues when 1 user was downloading a file and trying to do something else on the page (like load a new page or something) Threading ACTUALLY does do exactly what I want via `threading.Thread(...).start()`, so that will be used going forward Also, it seems to 3x faster that way, because with asyncio the page took 1 sec to load, with threading it takes 280 ms, which is weird even if we are doing things one at a time | |||
| 2024-08-22 | es | UltraQbik | |
| 2024-08-22 | Tweak a thing | UltraQbik | |
| 2024-08-22 | Add Content-Length header | UltraQbik | |
| 2024-08-22 | Update things slightly | UltraQbik | |
| 2024-08-22 | Kind of working API I guess? | UltraQbik | |
| 2024-08-22 | Move thing up | UltraQbik | |
| 2024-08-22 | Update path handling and API part | UltraQbik | |
| 2024-08-22 | Update API thing | UltraQbik | |
| 2024-08-22 | API seems to work | UltraQbik | |