401649 - (js-sjs) JS CGI support in httpd.js

Status: RESOLVED FIXED

(Testing :: General, defect)

Description

[Jeff Walden [:Waldo]]

I have a patch for this, but I haven't written a decent set of tests for it yet.  I'm currently using the subscript loader and just saying, "don't do stuff outside the promised APIs", which is technically perfectly fine given that handlers will have full privileges, but I still find it somewhat unsatisfying from a reduce-attack-surface-as-much-as-possible perspective.

This won't fix bug 396226 or make it possible to not block while generating the entirety of a request, because this can be fixed with relatively little code (~15K if I remember right) where that one can't.  It'll just let you dump the request-handling functions you'd use with registerPathHandler in files, so you don't have to have access to the actual server to have dynamic page generation (i.e. exactly the situation Mochitest is in).

Comment 1

[Jeff Walden [:Waldo]]

Attachment: Patch

Sadly I don't think I have a way to fully isolate the CGI script execution from the server itself, but since the scripts are privileged anyway it's more an aesthetic concern than anything else.

Comment 2

[Jeff Walden [:Waldo]]

Attachment: A file named "foo" shouldn't trigger the "foo" extension handling

I've been seeing more and more backups in testing over this recently; we need to get this in.

Comment 3

[Robert Sayre]

Comment on attachment 300588 [details] [diff] [review]
A file named "foo" shouldn't trigger the "foo" extension handling

>Index: netwerk/test/httpserver/httpd.js
>===================================================================

>+const ScriptableInputStream = CC("@mozilla.org/scriptableinputstream;1",
>+                                 "nsIScriptableInputStream",
>+                                 "init");

These streams might get removed from 1.9, aiui. Let's find out before we add tests that depend on them. Minus for that reason.

Nit: this is totally not a CGI (RFC 3875), even though I understand you meant something more general. Does Server JavaScript lead to an .sjs extension? Anyway, let's call it something else (anything you want).

Comment 4

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #3)
> >+const ScriptableInputStream = CC("@mozilla.org/scriptableinputstream;1",
> >+                                 "nsIScriptableInputStream",
> >+                                 "init");
> 
> These streams might get removed from 1.9, aiui.

Are you thinking of bug 414901? I'm pretty sure nsIScriptableInputStream isn't going anywhere.

Comment 5

[Jeff Walden [:Waldo]]

Attachment: cgi -> sjs, some driveby renaming

nsIScriptableInputStream is and has been the only way to access stream data for quite awhile; it absolutely is not going away for 1.9.  Note that that definition got moved into the server and *out* of a long-standing, extant test.  Neil's stuff is entirely different from what I use here.

I didn't know there was a full CGI RFC (thought it was at best a quasi-standard), but I don't really have a problem conflating CGI with server-side dynamic content in general (especially when said content has a better, safer, and more secure interface).  In the interests of not getting into too much bikeshedding and as I don't care that much anyway, I switched to SJS.

I've never liked the MozJSHTTP name; httpd.js is much nicer-sounding.  (Holy initialisms, Batman!  [for either name, actually])

Comment 6

[Robert Sayre]

Comment on attachment 300858 [details] [diff] [review]
cgi -> sjs, some driveby renaming

ah, my mistake.

Comment 7

[Jeff Walden [:Waldo]]

Checked in on trunk.

Comment 9

[Jeff Walden [:Waldo]]

Moving httpd.js bugs to the new Testing :: httpd.js component; filter out this bugmail by searching for "ICanHasHttpd.jsComponent".

Comment 10

[Jeff Walden [:Waldo]]

...and changing the QA contact as well.  Filter on the string "BugzillaQAContactHandlingIsStupid".