Preserve old Content-Type behaviour for bundles #51
Conversation
|
This solution assumes downloads from ASLO. Activities can be downloaded from other sources such as a school server. A more appropriate solution is for ASLO to identify activities with the correct mime_type. |
|
A school server would use the right Content-Type header. Are you aware of any school servers that use application/octet-stream instead? Yes, ASLO might be changed, but with Sugar Network dependent on ASLO and heavily used by Peru there are risks of regression, so it is better to fix Browse so it works as it did before. |
|
I have never seen this problem on a school server so I just don't know.
I am not a good source since I am installing an earlier version of
Browse from GSOC 2017 with jsfiddle.
Tony
…On 04/26/2017 09:42 AM, James Cameron wrote:
A school server would use the right Content-Type header. Are you aware
of any school servers that use application/octet-stream instead? Yes,
ASLO might be changed, but with Sugar Network dependent on ASLO and
heavily used by Peru there are risks of regression, so it is better to
fix Browse so it works as it did before.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#51 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAULkpElCrDYlbvJxlvd9mhIqyiK1HYZks5rzqEbgaJpZM4NHRPN>.
|
|
Hi, |
|
@tony37 that was GSOC 2016 ;-) |
|
Good point. Yes, browsers vary in their handling of
There is no commonly accepted standard; but using the same method as the most popular browsers may be a good starting point.
Browse-157.3 (WebKit API) effectively uses Browse-200 (WebKit2 API) effectively uses On the assumption that we cannot fix ASLO; I'm inclined to remove the conditional check for Should ASLO and mirrors be fixable; Browse-200 will only be broken with web repositories of activities that don't have the correct type in web server configuration. So there's still a small reason to fix Browse no matter what happens with ASLO; if we want Browse-200 to work in the same way as Browse-157.3. |
|
The goal is to determine if the downloaded file is an activity bundle
and, if so, install it. Pragmatically, Browse could check the file_path
for a .xo extension. Another option would be to use zipfile to ensure
the file is zip and has a file: activity/activity.info.
Tony
…On 04/28/2017 01:59 PM, James Cameron wrote:
Good point. Yes, browsers vary in their handling of |Content-Type|
header. Browsers may use, or not use, any of these sources of type;
* server response |Content-Type| header, (e.g.
|application/octet-stream|),
* suffix of client request path, (e.g. the URL ending in .xo),
* content bytes (e.g. using pattern recognition, like |magic(5)| or
|file(1)|)
There is no commonly accepted standard; but using the same method as
the most popular browsers may be a good starting point.
|Gio.content_type_guess| uses file path and content bytes.
Browse-157.3 (WebKit API) effectively uses |Gio.content_type_guess|
and ignores |Content-Type|.
Browse-200 (WebKit2 API) effectively uses |Content-Type| only,
defaulting to whatever WebKit2 chooses, which for ASLO is
|application/octet-stream|.
On the assumption that we cannot fix ASLO; I'm inclined to remove the
conditional check for |activities.sugarlabs.org| and call
|Gio.content_type_guess| always, and if the return is
|application/vnd.olpc-sugar| don't use |Content-Type| header.
Should ASLO and mirrors be fixable; Browse-200 will only be broken
with web repositories of activities that don't have the correct type
in web server configuration. So there's still a small reason to fix
Browse no matter what happens with ASLO; if we want Browse-200 to work
in the same way as Browse-157.3.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#51 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAULknr7oNHrQdWD3RQz0dgE2QyYokueks5r0YA-gaJpZM4NHRPN>.
|
|
Yes, that's what I said; Browse-157.3 did that, Browse-200 does not. I've researched to assess impact; affected now are users of Sugar on downstream distributions; Debian, Ubuntu, or Fedora. They have already packaged Browse-200. Latest SoaS is affected. No impact on OLPC OS because I'll be carrying a patch relative to upstream. |
quozl
changed the title
|
Rewritten; new commit description of d1fa67f as follows; Preserve old Content-Type behaviour for bundles Problem: bundles may be provided by servers with a Solution: restore Browse-157.3 behaviour by detecting bundles and ignoring the Regression introduced in Browse-200, did not occur in Browse-157.3. |
Problem: bundles may be provided by servers with a Content-Type of application/octet-stream instead of application/vnd.olpc-sugar, which when passed into the Journal prevents quick bundle installation. Solution: restore Browse-157.3 behaviour by detecting bundles and ignoring the Content-Type from the server. Regression introduced in Browse-200, did not occur in Browse-157.3. References: https://bugs.sugarlabs.org/ticket/4977 Signed-off-by: James Cameron <[email protected]> Tested-by: Frederick Grose <[email protected]>
|
Changed commit description to add Tested-by: Frederick Grose [email protected], and bug 4977. |
Problem: bundles downloaded with Mime-Type of application/octet-stream instead of application/vnd.olpc-sugar; breaking use of activities.sugarlabs.org. #48
Solution: detect downloads and change Mime-Type.
Regression introduced in Browse-200, did not occur in Browse-157.3.