- allow OPTIONS HTTP method to be handled by local webserver;
- add /connect_cloud endpoint;
- add new DropboxStorage constructor that works with JSON response instead of requesting that via shortcode;
- add CloudManager::connectStorage() overload for this new JSON flow.
/connect_cloud endpoint allows cross-origin request (via CORS HTTP headers) from cloud.scummvm.org, so user's browser sends the JSON response directly to ScummVM app, instead of the app requesting that response from the site.
This commit is WIP, introducing a new constructor for Dropbox only, and not changing the GUI part at all.
Local webserver's helper class, Reader, supported simple GET requests and POST form/multipart ones. The code for the latter was a bit specific, and didn't allow handling more generic POST requests.
This change adds ReaderMode enum, with RM_HTTP_GENERIC mode, that allows such generic requests to be handled. In Networking::Client class, that uses Reader, readContent() was renamed to readFirstContent(), and corresponds to previously existing POST form/multipart mode. readContent() should now be used for generic POST requests handling.
Instead of doing linear strcmp-like operation after every byte read, Reader now computes a "hash" of the needle it searches for and updates "hash" of the window contents. Now, it only does strcmp if window has the same "hash" as the needle, which also improves file upload speed for ScummVM's local webserver.
Instead of shifting bytes in the array every time we read 1 byte, Reader now has two "pointers": where it reads from and writes into. This makes the buffer "circular", and removes the unnecessary bytes shifting, which results in increased file upload speed (only for the LAN server; libcurl side stays intact).
Reader now reads headers into stream, and some checks are added there
and in UploadFileClientHandler, so if headers are too long, they are
treated as bad request.
Now Client reads the first headers block, then LocalWebserver decides
which Handler to use. In case of "/upload", UploadFileHandler is used.
But now it only knows the "path" parameter. If that's valid, actual
UploadFileClientHandler is created, which reads the contents of the
request and, when finds there an "upload_file" field, starts saving it
in the directory specified by "path".
With that we don't need temp files approach from Reader class.
Instead of keeping them in memory. Temp file name is generated to point
into ScummVM's working directory. That means that if user wanted to
upload file to the place with sufficient size, it would instead be
uploaded to ScummVM's working directory. Yet it's too early to parse the
target directory, so there is no way to generate temp file name within
that directory.
That means that if current buffer is over, reader will stop reading and
it's safe to call readResponse() again, so it would continue from the
place it left.
That should be part of the Client, I guess. Reader is not ready to
continue reading from place it stopped, but it already works as it
should for the case when whole content is available.
