Torsten,

> When running the application here my web images served by the internal
> KomHttp Server did'nt 
> display on the webpages.

  What is in the file pointed to by fullFilePath?

> After comparing the images I've found that
> ModFile>>processHttp 
> includes the following code:
> 
>           HttpResponse current: (HttpResponse 
> 				fromStream: (FileDirectory default readOnlyFileNamed: fullFilePath)).

  Depending on what you want it to do, one way the portion of code
should like is:

fileStream _ FileDirectory default readOnlyFileNamed: fullFilePath.
fileStream ifNil: [^ false].
HttpResponse current: (HttpResponse 
			fromStream: (fileStream binary contentsOfEntireFile readStream).

  The idea is to use #binary where the code shouldn't do
anything with encodings of the file contents.

  I haven't tried this code, so don't know if you can use a binary
stream there, though.  (But it should.)

(By the way, #isAFileNamed: check doesn't make too much sense.  You
can't tell if you can open a file until you try to open it.  Also,
keepng an opened file around doesn't look a great idea...)

(Looking at #fromStream: implementation, I think MultiByteFileStream
should implement #mimeType and adds the content-type: field based on
the converter...)

> I could easily fix the seaside image by changing
> FileStream(class)>>concreteStream to return a 
> StandardFileStream again - but I don't know about the side effects this will
> have in the 3.8 image.

  Yeah, it breaks many other places.

> Question left is how we can handle the 3.7/3.8 differences in
> Seaside/KomHttp and other applications.

  KomHttp should be updated.

  Who is the maintainer of KomHttp in these days?

-- Yoshiki