Seaside in V13 vs V12

[Louis LaBrunda]

Hi All,

I'm updating my clock program from VA Smalltalk V12 to V13.  It is designed to run under Linux on a Raspberry Pi.  But I do the development on Windows and can test a lot of it in the development environment.  The clock portion seems to be fine.  I use Seaside to allow a connection into the program from a web browser (mostly for settings).  The web pages seem to look and work just fine except the images (for icons) don't display.  The generated HTML looks the same.

I handle all file delivery from within Smalltalk.  I know there is Apache and other systems to handle file delivery.  I use to use it but they kept changing how to install it and how to set it up and the Regex stuff.  I got fed up with it and finally wrote Smalltalk/Seaside code to handle it.  I also deliver JavaScript and CSS files and they also don't look like they are making their way to the web browser.

Does anyone have any idea of changes to VA Smalltalk or Seaside in V13 that might account for this?

Lou

[Esteban A. Maringolo]

Hi Louis,

There were changes in Seaside from 12.0 to 13.0, but most of them were related with encoding and rendering Unicode entities. Everything else continues to work unmodified, including the apps delivered with Seaside itself (config, examples, etc.).

So it's hard to tell what could be the issue you're having without understanding what you mean by "handle all file delivery from within Smalltalk", does that mean that the images and such are part of a WAFileLibrary? Would it be possible for you to share a small piece of your code that showcases the issue you're experiencing?

Best regards,

Esteban Maringolo Senior Software Developer  emari...@instantiations.com  @emaringolo  /emaringolo  instantiations.com

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/c8ac12e5-55f1-4743-b817-50e356331444n%40googlegroups.com.

[Louis LaBrunda]

Hi Esteban,

Thanks for the reply.  I don't use WAFileLibrary.  I don't remember why.  I may have starter this before WAFileLibrary was around or it wasn't used much or I just didn't know much about it.  I have included some code below that I will get to in a minute.

The HTML sent to the web browser includes things like this:

src="../images/KscLogo.png"

href="../styles/jquery-ui.structure.css"

src="../javascript/jquery-ui.js"

The V12 and V13 output is the same so the problem is not in the web page generation.

The code below gets the requests from the web browser.  The #fileData variable in the last line:

aRequestContext respond: [:response | response contentType: mimeType; nextPutAll: fileData].

contains the file data.  I have break pointed the code there an everything looks good.  #fileData has the file data that it should have.  After that I don't know what happens.  Tomorrow, I will dig deeper and try to see why the data isn't returned to the browser.

Lou

handleFiltered: aRequestContext
  | file fileInfo fileData mimeType pathArray fileStream fileStream2 tempData file2 |
 
fileCache isNil ifTrue: [fileCache := LookupTable new].
pathArray := aRequestContext request uri path asOrderedCollection.
fileStream := WriteStream on: ''.
fileStream2 := WriteStream on: ''.
pathArray do: [:p | fileStream nextPutAll: p] separatedBy: [fileStream nextPut: $/].
file := fileStream contents.
(pathArray notEmpty and: [pathArray first = 'root']) ifTrue: [pathArray removeFirst].
fileStream2 nextPut: $/.
pathArray do: [:p | fileStream2 nextPutAll: p] separatedBy: [fileStream2 nextPut: $/].
file2 := fileStream2 contents.

fileInfo := fileCache at: file asSymbol ifAbsent: [].
tempData := fileInfo notNil ifTrue: [
self readFileIfNeeded: fileInfo.
mimeType := fileInfo mimeType.
fileInfo data.
] ifFalse: [''].

fileData := tempData isEmpty ifTrue: [
mimeType := WAMimeType textPlain.
file2, ' not found!'.
] ifFalse: [tempData].

aRequestContext respond: [:response | response contentType: mimeType; nextPutAll: fileData].

[Esteban A. Maringolo]

 Louis,

It doesn't seem to be Seaside specific, but I want to weed out any possible issues that might be out there in the wild, so I have more questions than answers for your problem:

1) Where is that `handleFiltered:` method implemented? 

1.b) Is it in a WARequestFilter of your own? 

2) Are you getting 404s on the browser dev tools for these files? 

2.b) What do you get if you request the file individually? (using curl or any other http client)

3) Is the readFileIfNeeded: method finding the files you want?

Regards,

Esteban Maringolo Senior Software Developer  emari...@instantiations.com  @emaringolo  /emaringolo  instantiations.com

To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/da5687b1-712f-4e36-8d26-e7c78a9cfa3en%40googlegroups.com.

[Louis LaBrunda]

Hey Esteban,

Thanks for the help.  Please don't feel bad about asking questions as they are almost as helpful as answers.  I will try to answer them in a moment.  First I want to say that I did something that may be part of the problem.  When installing V13 I tried something a little different.  I versioned all my config maps in V12 and then imported them into the V13 manager.  For the most part this went well.  It even imported the apps referenced in the maps (I didn't realize it would do that but was pleased it did).  When I start with a clean image I have abt.cnf code that (among other things) loads maps and features.  These two features don't seem to be present in V13:

z.ST: Seaside Core
z.ST: Seaside Testing

I'm not sure but it looks like maps for those two were loaded from V12 into V13 when I imported other maps.  I removed those names from my list of features to load and that stopped the error messages.  I also eventually purged these maps from the library.  I don't know if all that has anything to do with the problem but thought I should mention it.  It all else fails, I may start over.

Now to your questions:

1) Where is that `handleFiltered:` method implemented?

Two places: in #KscSeasideFileHandler which is a subclass of WARequestHandler, that calls the method I showed you that is in a class KscSeasideFileController, that know where the files live and are cached.

1.b) Is it in a WARequestFilter of your own?

No.

2) Are you getting 404s on the browser dev tools for these files?

Yes.

2.b) What do you get if you request the file individually? (using curl or any other http client)

Sorry, I'm not sure just how to do that.

3) Is the readFileIfNeeded: method finding the files you want?

Yes.

Lou

[Louis LaBrunda]

Hi Esteban,

I played around with curl on windows and it seems the text files (.css) do get delivered and have the same value from both V12 and V13.

The image files (binary .png) are short.  and seem to have different data.  Might I have a codepage/UTF8/whatever type of problem?

Lou

[Louis LaBrunda]

Hi,

It looks like the data I have in my #fileData variable in V13 is short and maybe a little different.  Therefor this doesn't look like a Seaside problem after all.  Give me a little time to see what may be causing it.

Lou

[Louis LaBrunda]

Hi,

My last post was in error.  The data I have in my #fileData variable in V13 is NOT short.  I traced things a little farther and it seems GRVASTUtf8CodecStream>nextPutAll: has changes from V12 to V13.

It was:

nextPutAll: aStringOrSymbolOrByteArray

stream nextPutAll: (
aStringOrSymbolOrByteArray isAscii
ifTrue: [aStringOrSymbolOrByteArray]
ifFalse: [codec encode: aStringOrSymbolOrByteArray])

but is now:

nextPutAll: aStringOrSymbol
"Encodes aStringOrSymbol and appends it to receiver's underlying stream."

stream nextPutAll: (
(aStringOrSymbol isAscii and: [(self isUnicodeComponent: aStringOrSymbol) not])
ifTrue: [aStringOrSymbol]
ifFalse: [codec encode: aStringOrSymbol])

The encoding probably messes up the data.  I will try forcing the unencoded to be used and see what happens.

Lou

[Louis LaBrunda]

Well, the changes to GRVASTUtf8CodecStream>nextPutAll: aren't the problem.  I still don't know what is.

Lou

[Esteban A. Maringolo]

Hi Louis,

If the data is binary (png, jpeg, etc.), the codec is not involved, so my suspicion is that it is something else.

You can debug higher in the request/response cycle, add a conditional breakpoint in WASstHttpServlet>>#doGet: (or #doMethod:) to see where you're getting the 404.

Best regards,

Esteban Maringolo Senior Software Developer  emari...@instantiations.com  @emaringolo  /emaringolo  instantiations.com

To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/b6a5ee96-2995-473c-9204-c8f2cf1df587n%40googlegroups.com.

[Louis LaBrunda]

Hey Esteban,

Thanks for keeping an eye one this.  Somewhere between my call of:

aRequestContext respond: [:response | response contentType: mimeType; nextPutAll: fileData].

and:

WASstServerAdaptor>process:

The data gets messed up.  Just to test, I temporarily changed WASstServerAdaptor>process: to read the file and answer that data and it worked.  I'm still trying to find where between the two points, things go wrong.

I looked at mime type to see if needed to be some kind of binary indication but that looks good.

Lou

[Louis LaBrunda]

Hi All,

I'm still digging into this but it is getting hairy.  It seems that the response for the request for an image file (png etc.) includes some text strings that may need code page (or whatever) conversion, and the file data that doesn't.  I will keep digging.  Hopefully there is some flag that I need to set so that the binary image data doesn't get converted.

Lou

[Mariano Martinez Peck]

Hi Louis,

Can you show me how are you starting the Seaside server? Are you specifying a GRCodec ? If so, which one? 

Thanks

To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/2c084653-5503-4fcd-9f60-22101305483an%40googlegroups.com.

--

Mariano Martinez Peck VAST Team Lead Senior Software Engineer  mp...@instantiations.com  @MartinezPeck  /mariano-martinez-peck  instantiations.com

[Louis LaBrunda]

Hi Mariano,

I use:

ServerAdaptor := WASstServerAdaptor port: port.
ServerAdaptor start.

That's it.

Lou

[Mariano Martinez Peck]

What happens if you do something like:

| adaptor |
adaptor := WASstServerAdaptor port: 8888.
adaptor codec: GRNullCodec new.
adaptor start.

Does that change anything?

Regards,

To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/46e7fb44-9958-49bf-adce-2859297e2580n%40googlegroups.com.

[Louis LaBrunda]

Hey Mariano,

Thanks a million!  That looks like it fixed it.  And thanks to Esteban for getting us this far.  Are there any other codecs that I should think about using?

Lou

[Esteban A. Maringolo]

If you were getting 404's when the png where requested, I don't see how changing a codec could make that answer a valid file. But I think I know what happened to you. 

You never set the response to be binary, so in older versions of VAST you were using the default GRNullCodec (that does not encode anything) and in the latest version we use the UTF-8 Codec by default, which was causing the binary content to be encoded in UTF-8, garbling the output of a PNG image.

The solution, I think, should be to set the response to be binary as follows:

aRequestContext respond: [:response | 

    response

      binary; "<-- add this"

      contentType: mimeType;

      nextPutAll: fileData

].

This will change the internal stream class of the response to use one that doesn't use a codec at all.

So go back to using the UTF-8 codec (by default) and changing the response to set the binary mode.

Best regards,

Esteban Maringolo Senior Software Developer  emari...@instantiations.com  @emaringolo  /emaringolo  instantiations.com

To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/e64ced7b-d306-41f0-8be5-de48acadff87n%40googlegroups.com.

[Louis LaBrunda]

Hi Esteban,

I like the look of your solution and will give it a try tomorrow.  I don't remember where it was or what I was looking at but I think I came across something that led me to believe the file data was considered binary.  So, I didn't look for a way to force it.

Lou

[Louis LaBrunda]

Hi Esteban, Everyone,

I'm very happy to report that Esteban's suggestion to add sending #binary to the response and going back to the default UTF-8 codec works.

Esteban, as for getting 404's when png files are requested, this is just a guess but maybe the web browser was confused by the bad data that was the converted file and a 404 error was the best it could come up with.

Question: The code where I added the #binary message also processes text files like .js and .css.  Calling them binary works but would it be better to only send #binary for the .png (and other image) files?

Lou