GNOME Bugzilla – Bug 720223
Proposed changes to the librygel-server HTTP processing logic
Last modified: 2015-02-19 13:02:44 UTC
Created attachment 263952 [details] [review] Proposed changes to the librygel-server http processing logic Attached is a patch that updates the HTTP processing logic to remove dependencies/assumptions related to file-accessible/user-supplied content and to improve compliance with DLNA standards. This change (and related changes filed in separate bugs) are significant. So a document is attached to Bug 720218 that attempts to explain the changes we're proposing for librygel-server in more detail. (https://bugzilla.gnome.org/attachment.cgi?id=263949) Also see bug 710628 which contained a preliminary version of these changes. I believe we've incorporated all the feedback we received. Comments and feedback are welcome.
Created attachment 271058 [details] [review] Proposed changes to the librygel-server http processing logic (few fixes + live mode updates) This is a refresh of the original patch which incorporates a couple fixes, additional DLNA compliance issues, and live mode updates. The patch should be reviewed as a whole. But here's a brief description of what's changed from the prior version: The DTCPClearTextByteSeek class was missed when incorporating the one-class-per-file feedback. This is now split into DTCPCleartextRequest/Response classes. HTTPGet, DataSink, and the HTTPGetHandlers now deal with resources of unknown duration/size. The HTTPSeek classes (and responses) now deal with ranges/resources of unknown size/duration. DLNAAvailableSeekRangeRequest/Response classes are added for supporting getAvailableSeekRange/availableSeekRange.dlna.org (for DLNA limited operation modes). DLNA caching requirements are supported (Vary and Pragma response support). (includes the alternate fix for bug 702555). HTTPRequest.end() now takes an optional reason string and the HTTPGet logic now provides Error.message as a reason code when calling end - providing the client much more descriptive error messages in the HTTP status response.
Created attachment 279481 [details] [review] Proposed changes to the librygel-server http processing logic (few fixes + live mode updates)
I think what I'm struggeling the most here is the term request. In "traditional" Rygel, request is the HTTP GET/HEAD/POST. Here, it's mostly a feature that the client requests from the server during a "tradional" request?
I struggled a bit with this and made the base class for responses HTTPResponseElement - which I think better captures the meaning and differentiates it from a response. Perhaps all the HTTPSeekRequest and HTTPResponseElement subclasses could have "Element" added to the end? It makes the names kind of long. But it's certainly avoids this confusion.
Let me know if you'd like us to make this change in our repo, btw...
This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version. After your distribution has provided you with the updated package - and if you have some time - please feel encouraged to verify the fix by changing the status of this bug report to VERIFIED. If the updated package does not fix the reported issue, please reopen this bug report.