Is there any reason why _nx_http_server_field_value_get is a private function in HTTP server?

I want to parse the HTTP request header in the request notify function to be able to handle cookies for session management.

I was only able to find the private function _nx_http_server_field_value_get for extracting header fields. Is there any reason for this function being private?

I can access it with an extern declaration, just wondering if I'm not meant to use it for some reason?

  • You should never use internal functions (and any other internal code like struct data types) because they are subject to change without notice. API and configurable parameters are preserved between releases such that legacy applications will always compile and run.

    There is a nx_http_server_get_entity_header API (which calls this field_value_get function) that returns the entity header. You would call this from the notify_request callback. Copy the code in nx_http-server_field_value_get into your own application, customize it as needed, and call that on the header returned from nx_http_server_get_entity_header(). That way you get essentially the same functionality. You would probably want to replace HTTP status returns and the nx_http_server_memicmp function with something else to protect your code if HTTP server code changes.

    Let me know if that helps,
    Janet
  • In reply to JanetC:

    Hello Janet,

    I guess copying that function is a possibility. I'm aware that internal functions are subject to change.

    Any chance to get this function as a public API in a future SSP version? I was a bit surprised to see that there is no public function to get the headers of the request, as this is quite a common task when handling HTTP requests.

    Best regards,
    Chris
  • In reply to ChrisS:

    Hi Chris

    I will check with our developers if there would be any reason not to make it an API or create a similar API. If they have no objections I will add it as a "work item" request for the next release.

    I agree, such a utility would be very useful for an HTTP server customizing its response to clients.

    Janet
  • In reply to JanetC:

    Hi Janet,

    thanks, that sounds great!

    I have one more question, this time about nx_http_server_content_get. I noticed a problem when the content of the HTTP request is spread across multiple TCP packets. Reading the code, it seems that further TCP packets are fetched only if the specified byte_offset is inside one of the further packets, but not if the Content-Length header is larger than the current packet.

    I would expect that function to copy either the Content length or the maximum specified buffer size bytes of data and fetch additional packets if needed or return an error if the next packet doesn't arrive or match the content length.

    It might be possible to write code around this issue by calling it multiple times with different offsets manually so that the function fetches additional packets, but this seems counterintuitive. Do you consider this as a bug?

    Best regards,
    Chris

  • In reply to ChrisS:

    For reference, here's an example code for reading POSTed JSON data that seems to work as I expected the function to work. return_post_config_result is a function from me which sends a NX_HTTP_STATUS_BAD_REQUEST response with some additional data. I've switched to the _extended versions of the _content_ functions but the basic ones should be similar.



    char        json[3000];
    UINT        byte_offset = 0;
    UINT        chunk_size = 0;
    ULONG       content_length = 0;

    if(nx_http_server_content_length_get_extended(&packet, &content_length) != NX_SUCCESS)
        return return_post_config_result(server, CCR_REJECT, 0, NX_HTTP_STATUS_BAD_REQUEST);

    if(content_length > sizeof(json) - 1)
        return return_post_config_result(server, CCR_REJECT, 0, NX_HTTP_STATUS_BAD_REQUEST);

    //Try to get HTTP body. We need to do this in a loop and specify offsets because nx_http_server_content_get will only
    //fetch further packets if the byte_offset is inside a further packet.
    while(byte_offset < content_length)
    {
        if(nx_http_server_content_get_extended(&server, &packet, byte_offset, &json[byte_offset], sizeof(json) - 1, &chunk_size) != NX_SUCCESS)
            return return_post_config_result(server, CCR_REJECT, 0, NX_HTTP_STATUS_BAD_REQUEST);
        byte_offset += chunk_size;
    }

    json[byte_offset] = '\0';

  • In reply to ChrisS:

    HI Chris,

    It looks like you found a deficiency in the NetX /Duo HTTP server. I checked documentation and other sources and there is no mention for handling the case you describe. How often is a HTTP header so large that the content length is found in a second packet ? Packets can be any size but the sender would surely want to optimize its packet pool to avoid the extra overhead of multi packet messages.

    But if this not an unusual scenario, I will discuss with our dev team and see what the recommend.

    Also we added the request to make _nx_http_server_field_value_get() an API to our development roadmap. Since it is not a lot of work, it might make it into the next release, 5.12 (but I have no idea when that is scheduled for release).

    Since this function is not declared as static, you can also declare it as ‘extern’ function to avoid hard copy. If this is going into release code, though, I think what I suggested before is safer. We don't change HTTP source code very often but best to be safe.

    Thanks,
    Janet
  • In reply to JanetC:

    Hello Janet,

    I'm not sure if you read my post correctly, my problem is not with the content length but with the content of the request being split into multiple packets.

    in my case I POST a form as JSON to be able to handle the server response in a single page application. When the form contains some string fields the HTTP packet size can easily be exceeded, e.g. 4 256 character strings in my case.
    The header itself should usually be in the first packet though, unless there's some authentification going on with longer session IDs, cookies or similar.

    I'm currently using the "extern" declaration as you suggested. I will check this again closer to our next release, maybe there's a new SSP release by then.

    Thanks,
    Chris
  • In reply to ChrisS:

    I do understand your post for the request spanning multiple packets, as separate from the use of _nx_http_server_field_value_get issue. The former is currently not supported. I am inquiring about if we can address this deficiency in HTTP server with our development team and what might be possible workarounds in the meantime. I did not hear back last week, so I will ping them again.

    Janet