Difference in headers upload/download vs static file, also in auth.wiki

146 views
Skip to first unread message

Nico de Groot

unread,
Apr 10, 2013, 12:14:07 PM4/10/13
to

While debugging why the <audio> tag behaves differently (at least in Mac Chrome) depending on specifying (1) a static link to a soundfile or (2) using the auth.wiki syntax ////2/sound.mp3  I notice quite a few differences in the headers. 

(1) static: <audio controls="controls"><source src="/bgo/static/media/test.mp3" /></audio

(2) download/auth.wiki() <audio controls="controls"><source src="/bgo/default/index/2/sound.mp3" /></audio>

The two sets of settings can be shown by using curl, see below. Because essentially you ask a file to be served from the file system, you expect the same headers. But there not the same.

It seems to me that extra headers and the cookie (and the session) in (2) are superfluous. And I discovered that the missing Last-Modified header causes the strange Chrome behavior.

I fixed it by monkey-patching the gluon/tools.py media function inside auth.wiki. But I'm not sure if it's ok like this. Maybe the response.download function should be patched too? My patch is at the bottom.  

What do you think?  Is this a good patch?  

I'm still on web2py version 2.2.1 ( will upgrade and test it on latest and trunk later, but I don't expect differences)

Nico


THE HEADERS

(1) MacBook-Air-van-Nico:~ ncdegroot$ curl -I 127.0.0.1:8000/bgo/static/media/test.mp3

HTTP/1.1 200 OK
Content-Length: 38660
X-Powered-By: web2py
Last-Modified: Tue, 18 Dec 2012 11:20:41 GMT
Pragma: cache
Cache-Control: private
Content-Type: audio/mpeg
Date: Sun, 07 Apr 2013 19:19:57 GMT
Server: Rocket 1.2.5 Python/2.7.3
Connection: keep-alive


(2) MacBook-Air-van-Nico:~ ncdegroot$ curl -I 127.0.0.1:8000/bgo/default/index/2/sound.mp3

HTTP/1.1 200 OK
Content-Length: 11310
Content-Disposition: attachment; filename=wh-aam.mp3
X-Powered-By: web2py
Set-Cookie:  session_id_bgo=127.0.0.1-93f3ed51-7469-4ad0-8f47-ac8d5c71b7b1; Path=/
Expires: Sun, 07 Apr 2013 11:19:33 GMT
Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Type: audio/mpeg
Date: Sun, 07 Apr 2013 11:19:33 GMT
Server: Rocket 1.2.5 Python/2.7.3
Connection: keep-alive


THE PATCH (concept)

The differences can be fixed by patching the media() function in the auth.wiki part

gluon.tools.py:
 
    def media(self, id):
        request, db = current.request, self.auth.db
        media = db.wiki_media(id)
        if media:
            if self.manage_permissions:
                page = db.wiki_page(media.wiki_page)
                if not self.can_read(page):
                    return self.not_authorized(page)
            request.args = [media.filename]
            return current.response.download(request, db)
        else:
            raise HTTP(404)
 
patched
 
    def media(self, id):
        request, db = current.request, self.auth.db
        media = db.wiki_media(id)
        if media:
            if self.manage_permissions:
                page = db.wiki_page(media.wiki_page)
                if not self.can_read(page):
                    return self.not_authorized(page)
            request.args = [media.filename]
            # patch ncdg
            m = current.response.download(request, db)
            current.session.forget() # get rid of the cookie
            current.response.headers['Last-Modified'] = (request.utcnow).strftime("%a, %d %b %Y %H:%M:%S GMT")
            del current.response.headers['Content-Disposition']
            current.response.headers['Pragma'] = 'cache'
            current.response.headers['Cache-Control'] = 'private'
            return m
            # /patch ncdg print headers
        else:
            raise HTTP(404)



Alan Etkin

unread,
Apr 8, 2013, 8:48:49 AM4/8/13
to web...@googlegroups.com

While debugging why the <audio> tag behaves differently (at least in Mac Chrome) depending on specifying (1) a static link to a soundfile or (2) using the auth.wiki syntax ////2/sound.mp3  I notice quite a few differences in the headers. 

I have a similar problem with web2py trunk Version 2.4.6-stable+timestamp.2013.04.07.19.55.04 and Firefox 19.0.2 (on Ubuntu)

I used the wiki interface for adding a link to an uploaded media (mp3 file) into a markmin wiki document. The media object is appended to the html response with <audio ...>... etc, but it is not shown in the browser. Using the audio source URL as address, the file is served as downloadable file (the browser shows a file download dialog).

Alan Etkin

unread,
Apr 9, 2013, 9:49:33 AM4/9/13
to web...@googlegroups.com
> I have a similar problem with web2py trunk Version 2.4.6-stable+timestamp.2013.04.07.19.55.04 and Firefox 19.0.2 (on Ubuntu)

Oops, it seems that Firefox does not support .mp3 files in <audio>. The browser throws a debugging message saying the media has invalid format and it hides the embedded media player. I tried replacing the wiki media file with a .ogg file, but then, I belive I found an issue about media files in web2py: .ogg files are automatically served with video content-type. I tried changing gluon/contenttype.py for mapping to audio/ogg instead of the currently used video/x-theora+ogg. That worked for the particular case of serving a sound file with .ogg extension. Shouldn't web2py always map .ogg to audio?

Massimo Di Pierro

unread,
Apr 9, 2013, 10:20:02 AM4/9/13
to web...@googlegroups.com
I changed.

Alan Etkin

unread,
Apr 9, 2013, 11:36:18 AM4/9/13
to web...@googlegroups.com
> changed.

I'm not sure about the change in the content-type, but I'll open a new thread because it is not related with the first issue posted by Nico.

Nico de Groot

unread,
Apr 10, 2013, 12:31:38 PM4/10/13
to
Same results for 2.4.6 Shouldn't we fix this? The second set is not ok, but are headers for the static version correct? I haven't researched the RFC's yet

Nico


Massimo Di Pierro

unread,
Apr 15, 2013, 12:05:20 AM4/15/13
to web...@googlegroups.com
Hello Nico, I opened a ticket about this and I will fix it asap.

Right now auth.wiki() return static files by delegating to response.downloads() which sets the headers. Your proposed patch fixed auth.wiki(). Which this be fixed in response.download instead? What would be the consequences?


On Sunday, 7 April 2013 14:49:26 UTC-5, Nico de Groot wrote:

While debugging why the <audio> tag behaves differently (at least in Mac Chrome) depending on specifying (1) a static link to a soundfile or (2) using the auth.wiki syntax ////2/sound.mp3  I notice quite a few differences in the headers. 

(1) static: <audio controls="controls"><source src="/bgo/static/media/test.mp3" /></audio

Reply all
Reply to author
Forward
0 new messages