Re: [narwhal] a few jsgi spec issues...

[Tom Robinson]

I'm forwarding this to the ServerJS mailing list, since that's probably where we should discuss spec changes.

On Aug 9, 2009, at 11:49 AM, Dean Landolt wrote:

I'm a bit concerned about some ambiguity in jsgi's PATH_INFO as specified (emphasis mine):

PATH_INFO: The remainder of the request URL‘s “path”, designating the virtual “location” of the request‘s target within the application. This may be an empty string, if the request URL targets the application root and does not have a trailing slash. This value may be percent-encoded when I originating from a URL.

This doesn't actually specify whether jsgi-compliant servers should or should not decode PATH_INFO, which is noted as a wsgi design flaw [1]. The proposed fix for wsgi2 is a set of RAW_* env vars [2], but jsgi can avoid this env pollution and specify that they SHOULD NOT be decoded, leaving the decoding to middleware (like jack.request). I don't really care how, but it ought to be addressed one way or another.

Specifying the PATH_INFO should not be decoded is fine with me.

Another issue is that methods on jsgi.input are not specified at all. It looks like jack has some assumptions (such as a read(number) method) but these aren't specified anywhere. I've already run into this while trying to get jack and nitro working in persevere. Also, this is another notable wsgi issue [3] that's caused problems. Looking at rack, they have specified the input stream a little more clearly, such as that it must have a rewind method (another issue that's already bit me in jsgi).

Presumably it will match the ServerJS definition of a input stream, but it's probably also worth enumerating the methods in the JSGI spec.

Here's the current proposal for the file streams: https://wiki.mozilla.org/ServerJS/Filesystem_API/A#.2AReader.2C_.2AUpdater

But yes, we need to determine if the input stream should be rewindable/seekable. I don't see why not.

Also, this is off-topic, but shouldn't the file "reader" streams be rewindable/seekable? (not just the "updater" streams)

Finally, it doesn't look like jsgi or rack specify whether middleware can call app(env) more than once (rather than having to build full on mock requests). This is precluded in wsgi by the start_response callable, but wsgi2 is dumping the callable and proposing a signature like rack and jsgi. I can't find any documentation on whether this pattern is allowed in rack, but it strikes me as useful (for instance, for middleware that splits multipart/alternative requests into individual calls). Looking at the jack code, some of the middleware seems to be designed to allow this (a lot of env key testing, for instance).

Not sure if I understand. Can you give an example?

[1] http://www.wsgi.org/wsgi/WSGI_2.0#decoding-script-name-path-info
[2] http://www.wsgi.org/wsgi/WSGI_2.0#no-encoding-horrors-any-more
[3] http://www.wsgi.org/wsgi/WSGI_2.0#readline-size

[Dean Landolt]

On Sun, Aug 9, 2009 at 3:24 PM, Tom Robinson <tlrob...@gmail.com> wrote:

I'm forwarding this to the ServerJS mailing list, since that's probably where we should discuss spec changes.

Good point.
 

Another issue is that methods on jsgi.input are not specified at all. It looks like jack has some assumptions (such as a read(number) method) but these aren't specified anywhere. I've already run into this while trying to get jack and nitro working in persevere. Also, this is another notable wsgi issue [3] that's caused problems. Looking at rack, they have specified the input stream a little more clearly, such as that it must have a rewind method (another issue that's already bit me in jsgi).

Presumably it will match the ServerJS definition of a input stream, but it's probably also worth enumerating the methods in the JSGI spec.

Here's the current proposal for the file streams: https://wiki.mozilla.org/ServerJS/Filesystem_API/A#.2AReader.2C_.2AUpdater

Thanks for the pointer -- I didn't realize streams were already specified. As long as there's a clear severjs definition of stream I imagine it would be enough to just reference it from the jsgi spec.

But yes, we need to determine if the input stream should be rewindable/seekable. I don't see why not.

Also, this is off-topic, but shouldn't the file "reader" streams be rewindable/seekable? (not just the "updater" streams)

It seems logical. Or rather than mandating it at least have an isRewindable test (or isSeekable).

Finally, it doesn't look like jsgi or rack specify whether middleware can call app(env) more than once (rather than having to build full on mock requests). This is precluded in wsgi by the start_response callable, but wsgi2 is dumping the callable and proposing a signature like rack and jsgi. I can't find any documentation on whether this pattern is allowed in rack, but it strikes me as useful (for instance, for middleware that splits multipart/alternative requests into individual calls). Looking at the jack code, some of the middleware seems to be designed to allow this (a lot of env key testing, for instance).

Not sure if I understand. Can you give an example?

Terrible example middleware:

function DuplicateCall(app){
  return function(env){
    app(env);
    app(env);
  }
}

Of course this would be stupid. But there have been times when writing wsgi middleware I'd wished I was able to clone the environ, massage it, and submit it multiple times. This is specifically disallowed in wsgi because of start_response, but not so in rack and jsgi. It'd probably be easier to just use something like jack's MockRequest for this, but I figure it would be good for it to be clarified whether this is even allowed at all.