VB6 FastCGI Server

Quote:

---

Originally Posted by jpbro

Code:

---

    With po_Request.Http.QueryParameters
        For ii = 0 To .KeyCount - 1
            lo_Json.IJsonObject.AddJsonObjectByKeyValuePairs "Query" & ii+1, .KeyByIndex(ii), .ValuesByIndex(ii)
        Next ii
    End With
End Sub

---

---

I've just dived into your code for the first time - and am not really sure (yet), what the purpose of these special Add-Functions is,
but the JSON-standard requires (with regards to adding "new stuff"):

1) in case a JSON-Object is the target you want to add-to: a Key and a Value
2) in case a JSON-Array is the target you want to add-to: only a Value (and no Key)

Values can be "plain, Values" (like Strings, Doubles, Integers, Boolean and the null-value) -
but also "Node-Values" (either another JSON-Array, or another JSON-Object - both encapsulated by the cCollection-Type).

So in that special case above, an add-method would only have to do (instead of the looping):

Code:

---

  lo_Json.IJsonObject.AddToObject "QueryParams", _
                            po_Request.Http.QueryParameters.Internal_cCollection_Clone

---

To put the whole Param-List in one single call into the "MotherObject" (target-Object) under the Key "QueryParams".

E.g. in case the target-object already contained two "plain-values" with the keys "FirstName" and "LastName" like that:

Code:

---

{
  "FirstName": "Fred",
  "LastName": "Flintstone" 
}

---

Then after the "single-line-add-call" it would e.g. contain:

Code:

---

{
  "FirstName": "Fred",
  "LastName": "Flintstone",
  "QueryParams":{
                    "URL":"Some/Url",
                    "HTTPS":true,
                    "etc":"pp"
                }
}

---

Olaf

Quote:

---

Originally Posted by Schmidt

I've just dived into your code for the first time

---

Thanks for taking a look :)

Quote:

---

Originally Posted by Schmidt

- and am not really sure (yet), what the purpose of these special Add-Functions is

---

I guess it's time to work on some better documentation.

The purpose of the Add* functions is to make it easy to add a JSON Object or JSON Array to an existing JSON (object or array) collection. If there is no pre-existing JSON collection, then the Add* methods will create a top level Object or Array instead (as if you called the Initialize method).

The comments in the Initialize method describe the various ways you can initialize the JSON collection:

Code:

---

  ' - A JSON string (VB6 String/UTF-16LE)
  ' - A JSON Byte Array (UTF-8)
  ' - A vbRichClient5 cArrayList object
  ' - A VbRichClient5 cCollection object that has been created as a JSONObject or JSONArray
  ' - A non-byte Array of any type (it will be added to the collection as a JSONArray)
  ' - Nothing object - an empty JSONObject collection will be created
  ' - Empty array (e.g. .Initialize Array()) - an empty JSONArray collection will be created.

---

So after initializing the JSON collection as an JSON Array or Object via the Initialize method, the Add* methods will allow you to to sub-arrays or sub-objects to the initialized collection.

The bug was that I wasn't collection a Name for the appended sub-arrays/objects when they were being appended to a JSON Object collection, but this has been fixed now (the first passed parameter of the ParamArray will be used as the Name for the appended data).

Quote:

---

Originally Posted by Schmidt

but the JSON-standard requires (with regards to adding "new stuff"):

1) in case a JSON-Object is the target you want to add-to: a Key and a Value
2) in case a JSON-Array is the target you want to add-to: only a Value (and no Key)

Values can be "plain, Values" (like Strings, Doubles, Integers, Boolean and the null-value) -
but also "Node-Values" (either another JSON-Array, or another JSON-Object - both encapsulated by the cCollection-Type).

---

Thanks for the clarifications - the code I pushed yesterday understands this now.

Quote:

---

Originally Posted by Schmidt

So in that special case above, an add-method would only have to do (instead of the looping):

Code:

---

  lo_Json.IJsonObject.AddToObject "QueryParams", _
                            po_Request.Http.QueryParameters.Internal_cCollection_Clone

---

---

That looks good as an extension too - being able to pass a collection to an Add method would be handy in some case too, but I still think there is value to have the ParamArray versions as well for cases where you just want to quickly add data using a single call without and pre-built collection around. For example:

Code:

---

  ' Responding to a call from the browser
  lo_Json.IJsonObject.AddJsonObjectByKeyValuePairs "status", 200, "message", "Everything was successful!"

---

produces:

Code:

---

{"status":200,"message":"Everything was successful!"}

---

or:

Code:

---

  ' Responding to a call from the browser
  lo_Json.IJsonObject.AddJsonObjectByKeyValuePairs "status", 200
  lo_Json.IJsonObject.AddJsonObjectByKeyValuePairs  "results", "message", "Everything was successful!", "someotherkey", "someothervalue"

---

produces:

Code:

---

{"status":200,"results":{"message":"Everything was successful!","someotherkey":"someothervalue"}}

---

Quote:

---

Originally Posted by jpbro

Hi dreammanor, happy to help :)

I've pushed some changes to the JSON builder/helper class that I hope will do the trick. Now when you want to add array or object data to an existing JSON object collection, the first passed value to AddJsonObjectByKeyValuePairs or IJson_AddJsonArrayByValues should be a string that will act as the object/array name within the parent JSON object.

Here's how I've rewritten your code to accommodate the new approach:

Code:

---

Private Sub IFcgiApp_ProcessRequest(po_Request As VbFcgiLib.CFcgiRequest, po_Response As VbFcgiLib.CFcgiResponse)
    ShowHttpQueryParameters po_Request, po_Response
End Sub

Private Sub ShowHttpQueryParameters(po_Request As VbFcgiLib.CFcgiRequest, po_Response As VbFcgiLib.CFcgiResponse)
    Dim ii As Long
    Dim lo_Json As VbFcgiLib.CBuilderJson
       
    Set lo_Json = po_Response.Builders.Builder(builder_Json)
             
    lo_Json.IJsonObject.AddJsonObjectByKeyValuePairs "sub", "ShowHttpQueryParameters"
   
    With po_Request.Http.QueryParameters
        For ii = 0 To .KeyCount - 1
            lo_Json.IJsonObject.AddJsonObjectByKeyValuePairs "Query" & ii+1, .KeyByIndex(ii), .ValuesByIndex(ii)
        Next ii
    End With
             
    lo_Json.Finish
End Sub

---

Hope that helps, but let me know if you encounter any further issues. Thanks for reporting the problem!

---

After clearing the cached files in Chrome, I tested the above code, and the new code does not seem to work.

When I input http://127.0.0.1/vbfcgiapp.fcgi, the browser shows "{" sub ":" ShowHttpQueryParameters "}"

When I input http://127.0.0.1/vbfcgiapp.fcgi?action=getcustomers, the browser shows "502 Bad Gateway"

Hi jpbro, I'm trying to build a test environment with RC5.cWebServer so that I can debug your FastCGI code in VB IDE.

My idea is as follows:

Use RC5.cWebServer to replace the mo_TcpServer(RC5.cTCPServer) in CFcgiServer, and generate CFcgiDownstream data in WebServer_ProcessRequest event. I don't know if this is feasible?

I'm not familiar with web development, so it's important for me to build a test environment that can debug source code in the VB6 IDE.

Hi dreammanor,

Sorry my mistake - the code should actually be as follows:

Code:

---

Private Sub IFcgiApp_ProcessRequest(po_Request As VbFcgiLib.CFcgiRequest, po_Response As VbFcgiLib.CFcgiResponse)
    ShowHttpQueryParameters po_Request, po_Response
End Sub

Private Sub ShowHttpQueryParameters(po_Request As VbFcgiLib.CFcgiRequest, po_Response As VbFcgiLib.CFcgiResponse)
    Dim ii As Long
    Dim lo_Json As VbFcgiLib.CBuilderJson
       
    Set lo_Json = po_Response.Builders.Builder(builder_Json)
             
    lo_Json.IJsonObject.AddJsonObjectByKeyValuePairs "sub", "ShowHttpQueryParameters"
   
    With po_Request.Http.QueryParameters
        For ii = 0 To .KeyCount - 1
            lo_Json.IJsonObject.AddJsonObjectByKeyValuePairs "Query" & ii+1, .KeyByIndex(ii), .ValuesByIndex(ii).ValueByIndex(0)
        Next ii
    End With
             
    lo_Json.Finish
End Sub

---

Note that I changed the call to .ValuesByIndex(ii) to .ValuesByIndex(ii).ValueByIndex(0). This is because in theory you can have multiple values with the same key name (it's rare and probably not a good idea, but it isn't against any specification as far as I know, so it had to be accommodated).

Regarding getting RC5 cWebServer linked up to a VBFCGI app - I don't think it is possible because I don't think it supports the FastCGI protocol (nor is there any way to tell it to forward particular queries to the FCGI backend).

Easier debugging would be nice, but I'll have to think of how to accomplish this. What I do now though is write code in MTests in the VbFcgiAppDemo project and call those tests from the Debug window. This does give you the ability to step though most of the code (it doesn't replicate actual calls from a browser, nor does it display data in a browser, but it does let you test your logic and see what will be sent downstream once you start doing actual browser testing).

Quote:

---

Originally Posted by jpbro

Hi dreammanor,

Sorry my mistake - the code should actually be as follows:

Code:

---

Private Sub IFcgiApp_ProcessRequest(po_Request As VbFcgiLib.CFcgiRequest, po_Response As VbFcgiLib.CFcgiResponse)
    ShowHttpQueryParameters po_Request, po_Response
End Sub

Private Sub ShowHttpQueryParameters(po_Request As VbFcgiLib.CFcgiRequest, po_Response As VbFcgiLib.CFcgiResponse)
    Dim ii As Long
    Dim lo_Json As VbFcgiLib.CBuilderJson
       
    Set lo_Json = po_Response.Builders.Builder(builder_Json)
             
    lo_Json.IJsonObject.AddJsonObjectByKeyValuePairs "sub", "ShowHttpQueryParameters"
   
    With po_Request.Http.QueryParameters
        For ii = 0 To .KeyCount - 1
            lo_Json.IJsonObject.AddJsonObjectByKeyValuePairs "Query" & ii+1, .KeyByIndex(ii), .ValuesByIndex(ii).ValueByIndex(0)
        Next ii
    End With
             
    lo_Json.Finish
End Sub

---

Note that I changed the call to .ValuesByIndex(ii) to .ValuesByIndex(ii).ValueByIndex(0). This is because in theory you can have multiple values with the same key name (it's rare and probably not a good idea, but it isn't against any specification as far as I know, so it had to be accommodated).

---

Great, the test code works fine.

Quote:

---

Originally Posted by jpbro

Regarding getting RC5 cWebServer linked up to a VBFCGI app - I don't think it is possible because I don't think it supports the FastCGI protocol (nor is there any way to tell it to forward particular queries to the FCGI backend).

Easier debugging would be nice, but I'll have to think of how to accomplish this. What I do now though is write code in MTests in the VbFcgiAppDemo project and call those tests from the Debug window. This does give you the ability to step though most of the code (it doesn't replicate actual calls from a browser, nor does it display data in a browser, but it does let you test your logic and see what will be sent downstream once you start doing actual browser testing).

---

Now, I can't simulate the IFcgiApp_ProcessRequest event in the Debug window or MTests.bas. When I input query parameters in the browser and the Web-Server doesn't return the result I want, I can't know where the problem is.

Quote:

---

Originally Posted by dreammanor

Now, I can't simulate the IFcgiApp_ProcessRequest event in the Debug window or MTests.bas. When I input query parameters in the browser and the Web-Server doesn't return the result I want, I can't know where the problem is.

---

I've got an idea for a CSimulator class that will allow you to simulate a browser request and have it loop back to your CFcgiApp_ProcessRequest method in the IDE. I'm working on this now, but it may take a bit of time to finish. If it works out, you should be able to write tests in a module and execute them from the Immediate window. From there you can step through your code to debug it.

I recommend updating to the version just published at GitHub - it includes improved resiliency to user's who are refreshing the browser rapidly (by holding down the F5 key for example).

Also, you can show a custom 404 HTML page (in the Nginx document root folder) when your FCGI app returns a status of 404.

Quote:

---

Originally Posted by jpbro

I've got an idea for a CSimulator class that will allow you to simulate a browser request and have it loop back to your CFcgiApp_ProcessRequest method in the IDE. I'm working on this now, but it may take a bit of time to finish. If it works out, you should be able to write tests in a module and execute them from the Immediate window. From there you can step through your code to debug it.

---

I'm looking forward to the new CSimulator. Extremely grateful.

I've just updated the VbFcgi GitHub repository with the new VbFcgiLib.CSimulator class. It is in an early state right now, but there is a SimulateRequest method that takes a URL and a reference to your IFcgiApp implementing class. It then builds FCGI request and response objects for passing to your IFcgiApp_ProcessRequest method, meaning you can now step through your app in the IDE.

To do this:

In a standard module in your FCGI application project, add some code like this:

Code:

---

Public Sub TestApp()
  Dim lo_MyApp As New CFcgiApp  ' Create an instance of your FCGI application
  Dim lo_Simulator As New VbFcgiLib.CSimulator  ' Create an instance of the simulator class

  ' Change the URL below to whatever URL you want to test
  lo_Simulator.SimulateRequest "http://localhost/myapp.fcgi?query1=value1;query2=value2", lo_MyApp
End Sub

---

Make sure to put a breakpoint (or Debug.Assert False) in your IFcgiApp_ProcessRequest method so that you can step through the code after calling TestApp in the Immediate window.

NOTE #1 - The simulator has only been lightly tested, so there are probably bugs. Please let me know if you run into any trouble!

NOTE #2 - The simulator does not currently support POST requests with HTTP body content.

Thank you so much, jpbro, it is really useful. I'm in Chinese Spring Festival and I'll start testing CSimulator a few days later. Wish every happiness will always be with you and your family!

Thanks for the kind words dreammanor, best wishes to you and your family too! :wave:

Quote:

---

Originally Posted by jpbro

I've just updated the VbFcgi GitHub repository with the new VbFcgiLib.CSimulator class. It is in an early state right now, but there is a SimulateRequest method that takes a URL and a reference to your IFcgiApp implementing class. It then builds FCGI request and response objects for passing to your IFcgiApp_ProcessRequest method, meaning you can now step through your app in the IDE.

To do this:

In a standard module in your FCGI application project, add some code like this:

Code:

---

Public Sub TestApp()
  Dim lo_MyApp As New CFcgiApp  ' Create an instance of your FCGI application
  Dim lo_Simulator As New VbFcgiLib.CSimulator  ' Create an instance of the simulator class

  ' Change the URL below to whatever URL you want to test
  lo_Simulator.SimulateRequest "http://localhost/myapp.fcgi?query1=value1;query2=value2", lo_MyApp
End Sub

---

Make sure to put a breakpoint (or Debug.Assert False) in your IFcgiApp_ProcessRequest method so that you can step through the code after calling TestApp in the Immediate window.

NOTE #1 - The simulator has only been lightly tested, so there are probably bugs. Please let me know if you run into any trouble!

NOTE #2 - The simulator does not currently support POST requests with HTTP body content.

---

Hi jpbro, I tested the CSimulator carefully and it worked very well. It is very convenient to use the CSimulator to debug the vbFcgiLib and vbFcgiApp code in the VB6 IDE. Now all the query parameters (including "imagebyindex" and "showparams") are working properly. I like FastCGI more and more, it's really a great product. Thank you so much.

Great, glad you found it helpful! I can imagine some further enhancements to allow you to simulate cookies & body content, but this will have to wait until I have a bit more time. Thanks again for testing it out, and let me know if you encounter any issues.

Very much looking forward to the new features. I'm testing how to transfer the binary data of a ADODB recordset.

Quote:

---

Originally Posted by jpbro

You can send raw Byte data downstream from the IFcgiApp_ProcessRequest method as follows:

Code:

---

        po_Response.WriteBytes MyByteArray  ' Where my byte array is any byte data
        po_Response.Finished

---

---

Hi, jpbro, I'm testing how to transfer the binary data of a SqliteDB or ADODB recordset using FastCGI. I rewrote your code based on what you and Olaf suggested:

Code:

---

Private Function Action_GetCustomersFromSqliteDB(po_Request As VbFcgiLib.CFcgiRequest, po_Response As VbFcgiLib.CFcgiResponse) As Boolean
    'On Error Resume Next
   
    Dim ii As Long
    Dim lo_Cnn As vbRichClient5.cConnection
    Dim lo_Cmd As vbRichClient5.cCommand
    Dim lo_Rs As vbRichClient5.cRecordset
       
    ' Create an in-memory database
    Set lo_Cnn = libRc5Factory.C.Connection(, DBCreateInMemory)
    lo_Cnn.Execute "CREATE TABLE mytable (code TEXT, value1 INTEGER, value2 INTEGER, value3 REAL)"

    ' Build random table data
    Set lo_Cmd = lo_Cnn.CreateCommand("INSERT INTO mytable (code, value1, value2, value3) VALUES (?,?,?,?)")
    For ii = 0 To 25
        With lo_Cmd
            .SetAllParamsNull

            .SetText 1, Chr$(65 + ii)
            .SetInt32 2, Int(Rnd * 100)
            .SetInt32 3, Int(Rnd * 100)
            .SetDouble 4, Rnd

            .Execute
        End With
    Next ii

    ' Get data into recordset
    Set lo_Rs = lo_Cnn.OpenRecordset("SELECT * FROM mytable")

    po_Response.WriteBytes lo_Rs.Content
   
    po_Response.Finished
   
    If envRunningInIde Then
        ' For debugging purposes, print the content that will be sent downstream
        Debug.Print "Getting data from SqliteDB finished!"
    End If
   
    Set lo_Rs = Nothing
    Set lo_Cmd = Nothing
    Set lo_Cnn = Nothing
End Function

---

Use CSimulator to debug it in the VB6 IDE and it works fine. However, when running in the Chrome browser, I got the following error:

Code:

---

An error occurred.
Sorry, the page you are looking for is currently unavailable.
Please try again later.

If you are the system administrator of this resource then you should check the error log for details.

Faithfully yours, nginx.

---

I checked the Nginx error log, the error message is as follows:

Code:

---

2018/02/23 18:55:07 [error] 13628#4532: *33 upstream sent invalid header while reading response header from upstream, client: 127.0.0.1, server: localhost, request: "GET /vbfcgiapp.fcgi?getcustomers=1 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9100", host: "127.0.0.1"

---

When you use the "raw" WriteBytes method (instead of one of the IBuilder helpers) then you are responsible for writing the HTTP headers as well. There is no byte-array IBuilder helper right now (though I've been considering writing one), so you will have to do something like this (I haven't had a chance to test, so let me know if there are any errors you can't get around):

Code:

---

  Dim la_Content() As Byte
             
  Set lo_Rs = libRc5Factory.C.Recordset
             
  la_Content = lo_Rs.Content
             
  po_Response.WriteBytes stringVbToUtf8("Content-Length: " & arraySize(la_Content) & vbNewLine)
  po_Response.WriteBytes stringVbToUtf8("Content-Type: application/octet-stream" & vbNewLine)
  po_Response.WriteBytes stringVbToUtf8("Content-Type: application/octet-stream" & vbNewLine)
  po_Response.WriteBytes stringVbToUtf8(vbNewLine)
  po_Response.WriteBytes la_Content

---

Hi jpbro, the above code works perfectly, and I've loaded the binary data returned by FastCGI into the FlexGrid. Thank you so much, happy weekend.

jpbro, now I can get FastCGI Json data with the following code:

Code:

---

    Dim Req As Object:      Dim B() As Byte
   
    Set Req = CreateObject("Winhttp.WinHttpRequest.5.1")

    With Req
        .Open "POST", "http://127.0.0.1/vbfcgiapp.fcgi?json_getdata=1", False
        .SetRequestHeader "Content-Type", "application/json"
        .Send vbNullString
        B = .ResponseBody
    End With
    ...

---

However, sometimes I want to pass the query parameters in another way, such as:

Code:

---

    With Req
        .Open "POST", "http://127.0.0.1/vbfcgiapp.fcgi", False
        .SetRequestHeader "Content-Type", "application/json"
        .Send "{""json_getdata"": ""1"""}"
        B = .ResponseBody
    End With
    ...

---

This method can pass more query parameters, but FastCGI doesn't recognize the query parameters emitted in Send method.

Hi dreammanor. When you are sending data upstream via body content, the content will be in the FCGI STDIN buffer.

If you are going to be passing all of your parameters upstream as JSON payloads, you could check the Content-Type value in FCGI Parameters object in your VBFCGI app. When you see an "application/json" content type, you can assume it is your list of parameters. For example:

Code:

---

  Dim lo_Json As VbFcgiLib.CBuilderJson
  Dim l_ContentType As String

  ' Check if the Content-Type header starts with "application/json"
  ' If so, we'll just reflect the JSON back downstream, but in your app you can parse it out to a vbRichClient5.cCollection
  ' object and then act on the passed parameters as required.
       
  l_ContentType = po_Request.Fcgi.Params.ValueByEnum(stdparam_ContentType)
 
  If Not stringIsEmptyOrWhitespaceOnly(l_ContentType) Then
      ' We split on ";" because the Content-Type header can include extra info like charset. e.g. Content-Type: application/json; Charset=UTF-8
      If LCase$(Split(l_ContentType, ";")(0)) = "application/json" Then
        ' JSON body content received
        Set lo_Json = po_Response.Builders.Builder(builder_Json)
     
        ' Get the JSON body content from the FCGI.Stdin object, and initialize our JSON builder helper with that same data
        ' to send back downstream to prove we received it OK       
        lo_Json.Initialize po_Request.Fcgi.Stdin.Content
             
        lo_Json.Finish
      End If
  End If

---

Hope that helps!

It's exactly what I need, thank you so much, jpbro.

Hi jpbro, in order to facilitate the future development, I will make a complete web debugging platform (debugging tools). Your CSimulator is great, and it has made it possible to debug most VbFcgi code in the VB6 IDE. There is only one minor problem, CSimulator can't simulate a real browser scene (that is, the process between sending URLs from the browser and VbFcgi start receiving the data). So I have an idea, using RC5.cWebServer to simulate this process, the process is as follows:

(1) winHttp sends a request to RC5.WebServer

(2) RC5.WebServer forwards this request to VbFcgi

(3) VbFcgi accepts the request from RC5.WebServer

(4) VbFcgi returns the processed result to RC5.WebServer (Note: As long as the above three steps can achieve the purpose of testing, the fourth step is not necessary.)


In other words, let RC5.WebServer to simulate a small part of the nginx function in the VB6 IDE. If this feature can be achieved, then all the VbFcgi code can be debugged in the VB6 IDE. I don't know whether this idea is feasible, I would like to hear the professional opinions from you and Olaf.

Hi jpbro, I have a few minor questions:

The vbFastCGI query parameters are case sensitive, for example, "Action=1" is different from "action=1". I checked the source code and found out why:

CHttpQueryParams

Code:

---

Private Sub Class_Initialize()
  Set mo_QueryParams = libRc5Factory.C.Collection(False, BinaryCompare)
End Sub

---

I'd like to know if it is necessary to change BinaryCompare to TextCompare?

In addition, HttpCookies are also case-sensitive:

CHttpCookies

Code:

---

Private Sub Class_Initialize()
  Set mo_Cookies = libRc5Factory.C.Collection(False, BinaryCompare)
End Sub

---

The second small question:

CFcgiStdIn

Code:

---

Public Function Content() As Byte()
  Dim la_Bytes() As Byte
  Dim l_CurPos As Long
 
  ' On Error Resume Next
 
  ' Get all available content in STDIN
 
  If Me.HasContent Then
      l_CurPos = mo_StdIn.GetPosition  ' Record current stream position
     
      mo_StdIn.SetPosition 0  ' Go to beginning of stream
      mo_StdIn.ReadToByteArr la_Bytes  ' Get all bytes
     
      mo_StdIn.SetPosition l_CurPos ' Reset stream position
     
  Else
    la_Bytes = Array()  ' Return empty array. LBound = 0, UBound = -1
  End If

  Content = la_Bytes
End Function

---

The TypeName of Array() is Variant, and the TypeName of la_Bytes is Byte, so "la_Bytes = Array()" will always have "Type mismatch" error. How can we get an empty byte-array with LBound = 0 and UBound = -1?

The third small question:

CFcgiApp

Code:

---

Private Sub IFcgiApp_ProcessRequest(po_Request As VbFcgiLib.CFcgiRequest, po_Response As VbFcgiLib.CFcgiResponse)
 ...
 ...
 ...

Final:
 If po_Response.IsFinished Then
    po_Response.Finished
 end If

end Sub

---

Sometimes we may forget to call po_Response.Finished, and if a IsFinished property (similar to IBuilder.IsFinished) is provided for CFcgiResponse, then we can execute the following code at the end of the sub:

Code:

---

If po_Response.IsFinished Then
    po_Response.Finished
 end If

---

Quote:

---

Originally Posted by dreammanor

The TypeName of Array() is Variant, and the TypeName of la_Bytes is Byte, so "la_Bytes = Array()" will always have "Type mismatch" error. How can we get an empty byte-array with LBound = 0 and UBound = -1?

---

Try assigning empty string like la_Bytes = vbNullString

cheers,
</wqw>

Quote:

---

Originally Posted by dreammanor

The vbFastCGI query parameters are case sensitive, for example, "Action=1" is different from "action=1".

---

My interpretation of RFC 3986 URI specifications leads me to believe that query parameter keys must be considered case-sensitive in order to be conformant:

Quote:

---

6.2.2.1. Case Normalization

For all URIs, the hexadecimal digits within a percent-encoding
triplet (e.g., "%3a" versus "%3A") are case-insensitive and therefore
should be normalized to use uppercase letters for the digits A-F.

When a URI uses components of the generic syntax, the component
syntax equivalence rules always apply; namely, that the scheme and
host are case-insensitive and therefore should be normalized to
lowercase. For example, the URI <HTTP://www.EXAMPLE.com/> is
equivalent to <http://www.example.com/>. The other generic syntax
components are assumed to be case-sensitive unless specifically
defined otherwise by the scheme (see Section 6.2.3).

---

So the scheme and host are case-insensitive, but the rest of the URI is case-sensitive unless specifically defined otherwise by the scheme (which unless I missed something, there is not such exception defined for HTTP/HTTPS). For that reason, I'd like to keep it as BinaryCompare - though perhaps I could make an option, I'm not sure that it's a great idea to be purposefully allowing non-conformant behaviour.

As for cookies, I found this: https://stackoverflow.com/questions/...case-sensitive

It states that while there is nothing in the RFC that defines cookies as having to be case-sensitive, they are de-facto case-sensitive due to the fact that cases-insensitivity is usually explicitly prescribed for various elements elsewhere in the RFC, and various browser implementations consider cookie keys to be case-senstitive. For those reasons, I think it's important to use binary comparison for cookie keys.

Quote:

---

Originally Posted by dreammanor

The second small question:

The TypeName of Array() is Variant, and the TypeName of la_Bytes is Byte, so "la_Bytes = Array()" will always have "Type mismatch" error. How can we get an empty byte-array with LBound = 0 and UBound = -1?

---

Good catch, thanks for reporting this bug. And thanks @wqweto for a succinct solution :)

I'll have this fixed and push to the GitHub repository soon.

@dreammanor, I've added an IsFinished property to the CFcgiResponse class. Please note though there there's a small bug in your logic for the end of sub code. It shuold be:

Code:

---

If Not po_Response.IsFinished Then
  po_Response.Finished
End If

---

(notice the "Not").

All changes/fixes are now published at the VbFcgi GitHub repository.

Quote:

---

Originally Posted by wqweto

Try assigning empty string like la_Bytes = vbNullString

cheers,
</wqw>

---

Hi wqweto, your solution is great, thank you.

Quote:

---

Originally Posted by jpbro

My interpretation of RFC 3986 URI specifications leads me to believe that query parameter keys must be considered case-sensitive in order to be conformant:



So the scheme and host are case-insensitive, but the rest of the URI is case-sensitive unless specifically defined otherwise by the scheme (which unless I missed something, there is not such exception defined for HTTP/HTTPS). For that reason, I'd like to keep it as BinaryCompare - though perhaps I could make an option, I'm not sure that it's a great idea to be purposefully allowing non-conformant behaviour.

As for cookies, I found this: https://stackoverflow.com/questions/...case-sensitive

It states that while there is nothing in the RFC that defines cookies as having to be case-sensitive, they are de-facto case-sensitive due to the fact that cases-insensitivity is usually explicitly prescribed for various elements elsewhere in the RFC, and various browser implementations consider cookie keys to be case-senstitive. For those reasons, I think it's important to use binary comparison for cookie keys.

---

What you say is very reasonable, and it's better to keep case sensitivity.

Quote:

---

Originally Posted by jpbro

@dreammanor, I've added an IsFinished property to the CFcgiResponse class. Please note though there there's a small bug in your logic for the end of sub code. It shuold be:

Code:

---

If Not po_Response.IsFinished Then
  po_Response.Finished
End If

---

(notice the "Not").

All changes/fixes are now published at the VbFcgi GitHub repository.

---

Thank you, jpbro. I've downloaded your new code.

Hi jpbro, I want to develop a Website-Builder similar to Wordprocess or Joomla, which is both a user self-building website platform and a content management system. I know most Website-Builders are developed using PHP + MySQL, and some are developed using PHP + GoLang + MySQL. You are a web expert and I would like to know if the VBFcgi can be used to develop a Website-Builder like Wordprocess or Jommla? Besides VBFcgi, what other tools or technologies do I need? Thanks.

Edit:
Olaf just gave me some very helpful suggestions.

I recently updated the demo source & binaries over at GitHub to show how you can use a thread shared in memory SQLite DB connection to share non-persistent data between instances of your VBFCGI application DLLs running under the same VBFCGI host process. This is based on an approach that Olaf demonstrated here: http://www.vbforums.com/showthread.p...-ThreadHandler

Hi dreammanor,

Sorry I missed your question back in June. I was busy with an illness in the family for a good chunk of the summer and things are just getting back to normal now.

The short answer is that you can develop just about anything you want - on the browser side of course you will be using HTML5, CSS, JavaScript (and any JS frameworks you like) to handle the front-end/UI. You can dynamically build this stuff in your VBFCGI app and send it downstream, or you can have static stuff built and served directly by Nginx. The static HTML5/JS stuff will then call back up to your VBFCGI app to get the dynamic data (usually in the form of JSON strings) and make changes to the UI.

In the middle/back-end you have your VBFCGI app, and it is where you will do all of your database IO. There are lots of options for your database, and the choice will depend on your expected workloads, how much concurrency you require, etc...

One thing you might want to look at is my basic "Template" demo approach. Essentially, you can write HTML5 pages that have special tags inserted where you want dynamic information to appear. The VBFCGI library will notice these tags and raise an event in your VBFCGI app. In your app you can then perform whatever processing you want (coded in VB6) then server back a response that the framework will use to replace the special tag with. Once all tags are processed, the framework will ship the completed HTML downstream for eventual consumption by a web browser.

It's a really broad topic to be honest, and it's difficult to give any specific recommendations on how to create a self-building website platform (it's not really my area of expertise). I'd be curious to see what Olaf suggested to you too :)

Quote:

---

Originally Posted by jpbro

I was busy with an illness in the family for a good chunk of the summer and things are just getting back to normal now.

---

Very sorry to hear that. I hope you and your family will always be healthy and safe.

Quote:

---

Originally Posted by jpbro

Hi dreammanor,

The short answer is that you can develop just about anything you want - on the browser side of course you will be using HTML5, CSS, JavaScript (and any JS frameworks you like) to handle the front-end/UI. You can dynamically build this stuff in your VBFCGI app and send it downstream, or you can have static stuff built and served directly by Nginx. The static HTML5/JS stuff will then call back up to your VBFCGI app to get the dynamic data (usually in the form of JSON strings) and make changes to the UI.

In the middle/back-end you have your VBFCGI app, and it is where you will do all of your database IO. There are lots of options for your database, and the choice will depend on your expected workloads, how much concurrency you require, etc...

One thing you might want to look at is my basic "Template" demo approach. Essentially, you can write HTML5 pages that have special tags inserted where you want dynamic information to appear. The VBFCGI library will notice these tags and raise an event in your VBFCGI app. In your app you can then perform whatever processing you want (coded in VB6) then server back a response that the framework will use to replace the special tag with. Once all tags are processed, the framework will ship the completed HTML downstream for eventual consumption by a web browser.

It's a really broad topic to be honest, and it's difficult to give any specific recommendations on how to create a self-building website platform (it's not really my area of expertise). I'd be curious to see what Olaf suggested to you too :)

---

Thank you for your detailed reply. The development of WebBuilder has not yet begun, mainly because I have not found a suitable solution.

Olaf's suggestion is in the following post:
http://www.vbforums.com/showthread.p...=1#post5298619

Quote:

---

Originally Posted by jpbro

I recently updated the demo source & binaries over at GitHub to show how you can use a thread shared in memory SQLite DB connection to share non-persistent data between instances of your VBFCGI application DLLs running under the same VBFCGI host process. This is based on an approach that Olaf demonstrated here: http://www.vbforums.com/showthread.p...-ThreadHandler

---

Hi jpbro, thank you very much. I'm currently developing a small project with Golang. After the project is completed, I'll start testing the latest vbFastCGI.

Are you writing the back end stuff in Golang? Or or you transpiling Golang to JS for the front end?

If you are doing the back end in Goland then maybe VBFCGI isn't relevant. The main purpose of VBFCGI is to write your backend in VB6 and there's only 2 reasons to do that:

• You have existing back end code from a mature Client/Server or N-tier application that you want to use on the web. There is no "re-writing" in this case, so you get to spend all/most of your efforts on the front end (using regular browser technologies like HTML5, JS, CSS, etc...)
  
• You don't want to learn another language for the back end stuff because you are most skilled at writing in VB6. This would be the case for new projects where the goal is to get the back end together as quickly as you are able (since you are fastest at coding in VB6), then focus on the front-end in regular web technologies like HTML5, JS, CSS, etc...

If you are starting a new project in a new (to you) language like Golang, it would probably be best to forego VBFCGI entirely and choose a more standard web stack.