[email protected](134): Range violation

[Abscissa]

On IIS 5.1 (XP Pro), this line (cgi.d, line 134) triggers a range violation:

assert(pathInfo[0 .. scriptName.length] == scriptName);

If the URL is: http://localhost/darticles/articles-debug.exe/

Then:

pathInfo == "/"
scriptName == "/darticles/articles-debug.exe"

[adamdruppe]

On Thu, Jul 21, 2011 at 05:00:51PM -0700, Abscissa wrote:

On IIS 5.1 (XP Pro), this line (cgi.d, line 134) triggers a range violation:

assert(pathInfo[0 .. scriptName.length] == scriptName);

Poo! I wonder if your comp and my comp do this differently... what
happens if you comment out the assert and the line a little under it
that slices pathInfo off in that similar way?

[Abscissa]

I think this may be relevent:

http://msdn.microsoft.com/en-us/library/ms525840(v=vs.90).aspx

[Abscissa]

Changing the IIS/requestUri-fixup block in cgi.d to the following should make it work in all cases (works for me at least):

        // Because IIS doesn't pass requestUri, we simulate it here if it's empty.
        if(requestUri.length == 0) {
            // IIS sometimes includes the script name as part of the path info - we don't want that
            if(pathInfo.length >= scriptName.length)
            {
                assert(pathInfo[0 .. scriptName.length] == scriptName);
                pathInfo = pathInfo[scriptName.length .. $];
            }
            requestUri = scriptName ~ pathInfo ~ (queryString.length ? ("?" ~ queryString) : "");

            iis = true; // FIXME HACK - used in byChunk below - see bugzilla 6339

            // FIXME: this works for apache and iis... but what about others?
        }

[adamdruppe]

On Thu, Jul 21, 2011 at 05:25:51PM -0700, Abscissa wrote:

Changing the IIS/requestUri-fixup block in cgi.d to the following should make it work in all cases (wors for me at least):

I see. Yeah, I'll try it on my Vista box next time I'm on it and save
the changes into my copy then.

Figures I should have RTFM'd!

[adamdruppe]

With my time constraints recently, I probably won't get to writing the web.d overview document in the next week, so let me summarize the URL structure here.

class Post : ApiObject {
this(yourapp app, string identifier) {}
void GET() {}
void somethingCool() {}
}

class yourapp : ApiProvider {
void method() {}
alias AnotherApiProvider more;
alias Post post;
}

/site/method

calls yoursite.method()

/site/post/

calls new Post(yoursite, "").GET()

/site/post/10

calls new Post(yoursite, "10").GET()

/site/post/10/somethingCool

calls new Post(yoursite, "10").somethingCool()

In general: object name / identifier string / method

If no method is given, it tries to call REQUEST_METHOD() - so GET, POST, etc.

And finally:

/site/more/

should call more._defaultPage() (I say should because I know a lot of child stuff is still buggy. It's supposed to chain post process, reflections, etc. and it doesn't do most of this, but the basics should at least work)

/site/more/otherMethod

calls more.otherMethod()

Generally, member ApiProviders are treated like subdirectories brought in.

[Abscissa]

Ahh, I see, thanks.

----- Original Message -----
From: "adamdruppe"
[email protected]
To: [email protected]
Sent: Thursday, July 21, 2011 9:04 PM
Subject: Re: [misc-stuff-including-D-programming-language-web-stuff]
[email protected](134): Range violation (#2)

With my time constraints recently, I probably won't get to writing the
web.d overview document in the next week, so let me summarize the URL
structure here.

class Post : ApiObject {
this(yourapp app, string identifier) {}
void GET() {}
void somethingCool() {}
}

class yourapp : ApiProvider {
void method() {}
alias AnotherApiProvider more;
alias Post post;
}

/site/method

calls yoursite.method()

/site/post/

calls new Post(yoursite, "").GET()

/site/post/10

calls new Post(yoursite, "10").GET()

/site/post/10/somethingCool

calls new Post(yoursite, "10").somethingCool()

In general: object name / identifier string / method

If no method is given, it tries to call REQUEST_METHOD() - so GET, POST,
etc.

And finally:

/site/more/

should call more._defaultPage() (I say should because I know a lot of
child stuff is still buggy. It's supposed to chain post process,
reflections, etc. and it doesn't do most of this, but the basics should at
least work)

/site/more/otherMethod

calls more.otherMethod()

Generally, member ApiProviders are treated like subdirectories brought in.

Reply to this email directly or view it on GitHub:
#2 (comment)

[adamdruppe]

anywho it seems to work now for me still so we should be fixed