Serving static images from Squeak 3.9

This week I moved my dev image to squeak 3.9 and I no encounter problems whem
I'm serving static image files from my FileRoot directory.

I am using the Identical images to the ones I used under 3.8 but firefox informs
me that...

The image "http://localhost:8080/foo.jpg" cannot be open because it contains errors

...IE is a little more helpful...

HTTP/1.1 500 Internal Server Error Content-type: text/html Content-length: 278
Internal Server Error
Error: Invalid utf8 input detected.

I've trawled through the previous discussions on 3.9 encoding but I'm not sure
if they are relevant to this issue.

Has anyone else encountered this issue or know of a solution?

Thanks
Alan

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Alan Capewell wrote:
> This week I moved my dev image to squeak 3.9 and I no encounter problems whem
> I'm serving static image files from my FileRoot directory.

I can't help you. Are you using David Shaffer's method[1]? I had the
same problem with images. Firefox said the images had errors (see
previous message subject: Working with CSS designers)

What does firebug tell you? Anything?

[1]http://www.shaffer-consulting.com/david/Seaside/GettingSoftware/index.html


--
brad fuller
  http://www.Sonaural.com/
  +1 (408) 799-6124


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I have.  I just resaved the image in a different format and it worked again.

Alan Capewell wrote:
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Jason Johnson wrote:
> I have.  I just resaved the image in a different format and it worked

pray tell, what different format? Image being the graphics? or image
being squeak?


--
brad fuller
  http://www.Sonaural.com/
  +1 (408) 799-6124


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Brad Fuller wrote: Oh sorry, that is ambiguous isn't it. :)  My brother-in-law sent me a
JPG that had that error, so I told him and he saved it as GIF and it worked.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Jason Johnson <jbjohns <at> libsource.com> writes:

I think I'm getting a little further with this...

I have been tracing the call through the KomHttpServer and discovered that in my
3.8 image the HttpResponse stream is of Class StandardFileStream  in my 3.9
image it is a MultiByteFileStream.  Difference being that the latter is then
getting passed through a UTF-8 conversion facility and I'm guessing my image is
not UTF-8 encoded.

Now all I need to do is work out why 3.9 is treating it as a
MultiByteFileStream.  If anyone has any clues please let me know - otherwise
I'll just kepp searching

Thanks
Alan


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Alan Capewell <alan.capewell <at> softwareag.co.uk> writes:

OK I have got round this for now.

I have downloaded Ramon's 3.9 image (see www.onsmalltalk.com) and I can get
files to serve like I do from my old 3.8 image.

I don't yet know the full significance but my failing 3.9 image had
KomHttpServer at version gk.6 and seaside at 2.7a1-mb.205.  Ramon's image has
KomHttpServer at gk.14 and seaside at 2.7a1-rjl.156

When I get some more time I'll try to track down what versions of what
introduced or remove the problem a little more sientifically.

BTW If your reading Ramon - you've made a great job of the look and feel of
the image.

Thanks
Alan



_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Alan Capewell wrote:
Can you tell us the method used to serve static images?
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Brad Fuller <brad <at> sonaural.com> writes:

>
> Alan Capewell wrote:
> > Alan Capewell <alan.capewell <at> softwareag.co.uk> writes:
> >
> >> I think I'm getting a little further with this...
> >>
> >> I have been tracing the call through the KomHttpServer and discovered that
 in
> >> my
> >> 3.8 image the HttpResponse stream is of Class StandardFileStream  in my 3.9
> >> image it is a MultiByteFileStream.  Difference being that the latter is
 then
> >> getting passed through a UTF-8 conversion facility and I'm guessing my
image
> >> is not UTF-8 encoded.
> >>
> >> Now all I need to do is work out why 3.9 is treating it as a
> >> MultiByteFileStream.  If anyone has any clues please let me know -
otherwise At the moment I'm just letting Kom serve the files, it makes my image a little
more portable and self contained.  For production purposes I think serving
static images from apache will be more appropriate.

I have used David Shaffer's guide to starting the web server (see
http://www.shaffer-consulting.com/david/Seaside/GettingSoftware/index.html) and
then I simply put my files into the "FileRoot" (or whatever you choose to call
it) directory.

I then just call http://localhost:9090/foo.jpg



_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Alan,

here is a fix. I am using the squeak-dev image (#93), and I am also
using the method from

  http://www.shaffer-consulting.com/david/Seaside/GettingSoftware/index.html

i.e. you use KomHttpServer to serve the files from the hard disk. As
you say, MultiByteFileStream is used for the response, so UTF-8
conversion is performed which mixes up the bits in the image.
Essentially, we want to treat the images as binary files that are
passed through unchanged.

The serving is done in ModFile, and I have patched this to make the
response stream binary for every request. Works for me. Would that be
a viable fix for the problem?

ModFile>>processHttp
        | fullFilePath method response |
        method := ModCore method.
        (#(#GET #POST ) includes: method)
                ifFalse: [^ false].
        fullFilePath := ModDoc fullFilePath.
        (FileStream isAFileNamed: fullFilePath)
                ifFalse: [^ false].
        self processSubModules
                ifTrue: [^ true].
        response := HttpResponse
                                fromStream: (FileDirectory default readOnlyFileNamed: fullFilePath).
        "Make the response contents stream binary. We are serving files
        so we want to serve them without any encoding / decoding interfering,
        right? "
        response contents binary.
        HttpResponse current: response.
        ^ true


Cheers

Matthias

On 3/15/07, Alan Capewell <[hidden email]> wrote: _______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> BTW If your reading Ramon - you've made a great job of the
> look and feel of
> the image.
>
> Thanks
> Alan

Thanks!

Ramon Leon
http://onsmalltalk.com 

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Matthias Berth <matthias.berth <at> googlemail.com> writes:

Hi Matthias

That works for me.  Not sure if it will create and UNIX-DOS Linefeed trauma but
I am not using it to transfer ascii files anyway.

Thanks for your help

Alan




_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside