|
|
Discuss
>
WebGUI Dev
|
|
|
User
|
knowmad
|
|
Date
|
11/10/2006 6:35 am
|
|
Views
|
2082
|
|
Rating
|
4
Rate [ | ]
|
|
|
Previous
·
Next
|
knowmad
|
Date: 11/10/2006 6:35 am · Subject: WebGUI request handling & response headers · Rating: 4
I'm looking into a bug I've reported[1] regarding headers not being set correctly for images. I've confirmed the behavior I reported by uploading an image to the demo server. I'd like to get this fixed since it's impacting our development work. It should be a simple matter of sending the correct MIME type header to the browser. However, I'm still learning the ropes of how a request is processed through wG and could use some help. So far I've found where the www_view method is called in the WebGUI::Asset::File module which I think is the method that processes the request. I can see where the data is being sent but the header is never being set. Is this something that should occur in the www_view method or does it take place somewhere else. What API should I be looking at to find how to set the header? I'll be glad to supply a patch if I can get this fixed for our servers. Thanks, William
[1] http://www.plainblack.com/bugs/tracker/invalid-mime-type-set-for-images
|
| Back to Top |
Rate [ | ]
|
| |
JT
|
Date: 11/10/2006 9:55 am · Subject: Re: WebGUI request handling & response headers · Rating: 7
> So far I've found where the www_view method is called in the
> WebGUI::Asset::File module which I think is the method that
> processes the request. I can see where the data is being sent but
> the header is never being set. Is this something that should occur
> in the www_view method or does it take place somewhere else. What
> API should I be looking at to find how to set the header? I'll be
> glad to supply a patch if I can get this fixed for our servers.
If this is for an image you'll likely want to look at
WebGUI::Asset::File::Image. Setting mime types is easy, you just do:
$session->http->setMimeType("text/html");
However, both the image and file assets don't actually serve up those
files. Instead, they send redirects that point to the file in the /
uploads folder, and from there Apache sends the appropriate mime type.
JT ~ Plain Black
ph: 703-286-2525 ext. 810
fax: 312-264-5382
http://www.plainblack.com
I reject your reality, and substitute my own. ~ Adam Savage
So far I've found where the www_view method is called in the WebGUI::Asset::File module which I think is the method that processes the request. I can see where the data is being sent but the header is never being set. Is this something that should occur in the www_view method or does it take place somewhere else. What API should I be looking at to find how to set the header? I'll be glad to supply a patch if I can get this fixed for our servers. If this is for an image you'll likely want to look at WebGUI::Asset::File::Image. Setting mime types is easy, you just do:
$session->http->setMimeType("text/html"); However, both the image and file assets don't actually serve up those files. Instead, they send redirects that point to the file in the /uploads folder, and from there Apache sends the appropriate mime type. JT ~ Plain Blackph: 703-286-2525 ext. 810fax: 312-264-5382http://www.plainblack.com I reject your reality, and substitute my own. ~ Adam Savage
|
| Back to Top |
Rate [ | ]
|
| |
dwilson
|
Date: 11/10/2006 10:10 am · Subject: Re: WebGUI request handling & response headers · Rating: 6
… except that they do stream the files directly now, because I had to change that to make it work with the exporter, which I suppose is what broke this. D'oh.
|
| Back to Top |
Rate [ | ]
|
| |
knowmad
|
Date: 11/10/2006 10:15 am · Subject: Re: WebGUI request handling & response headers · Rating: 0
Ahh, the culprit 'fesses up . So can we add support for mime types to the kludge or fix the kludge?
|
| Back to Top |
Rate [ | ]
|
| |
knowmad
|
Date: 11/10/2006 10:14 am · Subject: Re: WebGUI request handling & response headers · Rating: -7
Thanks for the response. I looked at the www_view method in WebGUI::Assets::File::Image; it calls back to its parent which is WebGUI::Assets::File. The code I'm seeing in W::A::File is not doing a redirect: # Kludge for now to make this work with the exporter. my $path = $self->getStorageLocation->getPath($self->get('filename')); my $fh = eval { FileHandle->new($path) }; defined($fh) or return ""; binmode $fh or ($fh->close, return ""); my $block; while (read($fh, $block, 16384) > 0) { $self->session->output->print($block, 1); } $fh->close; return 'chunked';
Perhaps whoever put the "kludge" in there didn't realize it would break the expected behavior? William PS: How do you get quoting in the rich text editor? Or are you replying via your email client?
|
| Back to Top |
Rate [ | ]
|
| |
dwilson
|
Date: 11/10/2006 10:28 am · Subject: Re: WebGUI request handling & response headers · Rating: 2
The comment is probably a little misleading. It's not really a kludge, by itself. :-) The kludgy part is that right now there's no way for www_view to be notified when it's being called in an export; it does have to copy it directly for export because there isn't really an HTTP stream in that case, but when it's not doing the export it would be better to pass it back to Apache. The direct way theoretically works in both cases as far as the data (though it's probably not as fast), but I forgot to add the MIME type handling, apparently. Hmm. The theoretically-correct solution is probably to make the exporter notify www_view that it's doing an export, and for file assets to switch their behavior based on that. I didn't see any convenient way of flagging that at the time, IIRC.
|
| Back to Top |
Rate [ | ]
|
| |
colink
|
Date: 11/10/2006 10:34 am · Subject: Re: WebGUI request handling & response headers · Rating: -1
maybe you could use $session->stow ???
|
| Back to Top |
Rate [ | ]
|
| |
knowmad
|
Date: 11/10/2006 10:50 am · Subject: Re: WebGUI request handling & response headers · Rating: 8
On Fri, Nov 10, 2006 at 10:28:39AM -0600, drake@plainblack.com wrote:
> The comment is probably a little misleading. It's not really a kludge, by
> itself. :-) The kludgy part is that right now there's no way for www_view to
> be notified when it's being called in an export; it does have to copy
> it directly for export because there isn't really an HTTP stream in
> that case,...
I see.
> ...but when it's not doing the export it would be better to pass it
> back to Apache.
I agree.
> The direct way theoretically works in both cases as far as the data (though
> it's probably not as fast), but I forgot to add the MIME type handling,
> apparently. Hmm.
Right now, I don't care as much about performance as much as
functionality. It seems the easiest fix for us, since we don't use
export, is to restore the previous behavior.
> The theoretically-correct solution is probably to make the exporter notify
> www_view that it's doing an export, and for file assets to switch their
> behavior based on that. I didn't see any convenient way of flagging that at
> the time, IIRC.
What about an ENV or PerlVar setting? That seems pretty simple but I'm
not familiar with how the exporter works in wG.
William
--
Knowmad Technologies
http://www.knowmad.com
|
| Back to Top |
Rate [ | ]
|
| |
JT
|
Date: 11/10/2006 11:05 am · Subject: Re: WebGUI request handling & response headers · Rating: 8
> The theoretically-correct solution is probably to make the exporter
> notify www_view that it's doing an export, and for file assets to
> switch their behavior based on that. I didn't see any convenient
> way of flagging that at the time, IIRC.
Let's not start adding flags to stuff. Instead, let's add a method
called exportView or something, that normally just calls www_view()
but that can be overridden on a per asset basis. That way we can have
completely different behavior for exporting than we do for viewing if
needsbe on a per asset basis.
JT ~ Plain Black
ph: 703-286-2525 ext. 810
fax: 312-264-5382
http://www.plainblack.com
I reject your reality, and substitute my own. ~ Adam Savage
The theoretically-correct solution is probably to make the exporter notify www_view that it's doing an export, and for file assets to switch their behavior based on that. I didn't see any convenient way of flagging that at the time, IIRC.
Let's not start adding flags to stuff. Instead, let's add a method called exportView or something, that normally just calls www_view() but that can be overridden on a per asset basis. That way we can have completely different behavior for exporting than we do for viewing if needsbe on a per asset basis.
JT ~ Plain Blackph: 703-286-2525 ext. 810fax: 312-264-5382http://www.plainblack.com I reject your reality, and substitute my own. ~ Adam Savage
|
| Back to Top |
Rate [ | ]
|
| |
|
|
OReilly by Albert2 - Fri @ 09:09am Glad to be here by patspam - Fri @ 01:59am Re: New Default Templates: community input by patspam - Thu @ 06:22pm
|