View Issue Details

IDProjectCategoryView StatusLast Update
0006670GNUnetfile-sharing servicepublic2020-12-26 06:59
Reportercy1 Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Platformx86_64OSLinuxOS VersionGentoo
Product VersionGit master 
Summary0006670: limited methods to de-serialize a CHK
DescriptionI've been fiddling with a web server that goes along the lines of: http://localhost:12345/chk/.... and I noticed that in the entire GNUnet source code, there is only one place a CHK URI may be created, from a serialized form without having the data. That "uri_chk_parse" function in fs/fs_uri.c is set to deliberately fail with no error message, if the input data is not prefixed with "gnunet://fs/". So either I have to make a redundant copy of the URI just so I can prefix it with gnunet://fs/, or else I have to require URIs like http://localhost:12345/gnunet://fs/CHK/... for no reason other than the parser is set to fail without that prefix.

I would think there was a function to take the two hashes and the file length, and produce a GNUNET_FS_Uri, but the only thing exposed will only take a hex-encoded UTF-8 URI that begins in "gnunet://fs/chk/."

I'd love to use the "gnunet:" schema, but I don't trust our browsers to even come close at dealing with gnunet, when downloads are better happening in a separate background process with progress updates. So I'd really like to make a web interface using just "http" at "localhost." But this method of getting a GNUNET_FS_Uri from a string is just really clunky. Could we possibly have a function like this?

GNUNET_FS_Uri* GNUNET_FS_uri_chk_create(struct GNUNET_HashCode key, struct GNUNET_HashCode query, uint64_t file_length) {
    FileIdentifier fi;
    fi.chk.key = key;
    fi.chk.query = query;
    fi.file_length = file_length;
    GNUNET_FS_Uri* ret = GNUNET_new(struct GNUNET_FS_Uri);
    ret->type = GNUNET_FS_URI_CHK;
    ret->data.chk = fi;
    return ret;
}

I suppose it's kind of pedantic. I can rewrite all the URIs submitted to internally start with gnunet://fs/chk/. Just seems like it'd be a little less interface reliant if I could extract the hashes myself, and create the CHK without providing a UTF-8 encoded string starting with "gnunet://fs/chk/" with two AsciiEncoded hashes and an ascii encoded base 10 length. In particular, if I want to save the current running downloads and resume them later, it'd be nice to be able to just save the HashCodes/file_length to disk, instead of rebuilding that gnunet://fs/chk/ URI again.
TagsNo tags attached.

Activities

There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2020-12-26 06:59 cy1 New Issue