7 May
2005
7 May
'05
5:38 p.m.
Lukas
Thanks for the tips. Got it serving the image file at last, but its not
a pretty sight....
'*?action=SWMimeView*' produced a *ByteArray doesNotUnderstand
#squeakToIso. *Its blowing up in *SWKom>>#prepareResponse: *Im guessing
thats becuse it thinks that swResponse is html, rather than a mime time?
I can put a ugly hack in make it work, but im sure there must be a
better alternative......
/prepareResponse: swResponse
| komResponse |
komResponse := HttpResponse new
contentType: swResponse type squeakToIso;
status: (HttpResponse statusSymbolFor: swResponse
status);
contents: *((swResponse stream contents respondsTo:
#squeakToIso) ifTrue: [swResponse stream contents squeakToIso] ifFalse:
[swResponse stream contents asString]) readStream*;
yourself.
self prepareResponseHeader: komResponse from: swResponse.
swResponse cookies isEmpty ifFalse: [
self prepareResponseCookie: komResponse from: swResponse ].
^komResponse
/
If not, make sure that the mime type in the edit
dialog of the image
is set properly, it should be something like image/jpeg, image/ gif,
... Early ports ofSmallWiki didn't passed this information from the
web-server to SmallWiki, but I think that has been fixed. Another
thing you might want to check (in an
It knows it is an image/gif, but it ignors requests to embed the image.
Early on I thought that maybe I was running an old version of smallwkik.
Someone had prepared an image with smallwiki already loaded, and thats
the image I downloaded. Comparing it to the one in squeak map showed no
differences. Also tried the VW version, but that was even worse.
Any more suggestions?
Daniel