Traffic Server
  1. Traffic Server
  2. TS-817

TSFetchUrl/TSFetchPages does not work with HTTP/1.1 requests

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.0.0
    • Fix Version/s: 5.2.0
    • Component/s: TS API

      Description

      The API calls TSFetchUrl/TSFetchPages do not work with HTTP/1.1 requests. The implementation seems to use the "end of the connection" to signal the user callback function, which is not the case on persistent connections.

        Issue Links

          Activity

          Hide
          vijaya bhaskar mamidi added a comment -

          The API should work fine even with 1.1 request . FetchURL/Pages uses the HTTPConnectAPI which eventually uses the HTTP state machine, which eventually uses the right version to talk to Origin Sever.

          So the diagram looks some thing like this.
          plugin-API-State Machine-Origin Server

          as you can see above the version between plugin and API does not really matter and API always uses 1.0 request and creates a new state machine.

          Also , you can see that persistent connections to client or Origin Server is not based on the request from plugin to API.

          I have the following questions :
          Have you tested the API with 1.1 requests?
          How are you using the API ?

          Thanks,
          Vijay

          Show
          vijaya bhaskar mamidi added a comment - The API should work fine even with 1.1 request . FetchURL/Pages uses the HTTPConnectAPI which eventually uses the HTTP state machine, which eventually uses the right version to talk to Origin Sever. So the diagram looks some thing like this. plugin- API-State Machine -Origin Server as you can see above the version between plugin and API does not really matter and API always uses 1.0 request and creates a new state machine. Also , you can see that persistent connections to client or Origin Server is not based on the request from plugin to API. I have the following questions : Have you tested the API with 1.1 requests? How are you using the API ? Thanks, Vijay
          Hide
          Naveen added a comment -

          Yes, I understand the request works for 1.0 requests and underneath it transforms to 1.1 request in the state machine. I am changing my request explicitly to 1.0 before I call TSFetchURL. However, one would expect it to work with 1.1 request passed to the TSFetchURL as well, regardless what happens within state machine. Passing a 1.1 request freezes the server till time out.

          Show
          Naveen added a comment - Yes, I understand the request works for 1.0 requests and underneath it transforms to 1.1 request in the state machine. I am changing my request explicitly to 1.0 before I call TSFetchURL. However, one would expect it to work with 1.1 request passed to the TSFetchURL as well, regardless what happens within state machine. Passing a 1.1 request freezes the server till time out.
          Hide
          vijaya bhaskar mamidi added a comment -

          I agree that it should work with 1.1 requests , if it is timing out there might be a bug in the API when it is changing the request to 1.0

          -Vijay

          Show
          vijaya bhaskar mamidi added a comment - I agree that it should work with 1.1 requests , if it is timing out there might be a bug in the API when it is changing the request to 1.0 -Vijay
          Hide
          vijaya bhaskar mamidi added a comment -

          Hi Naveen,

          Are you seeing the timeouts for 1.1 requests? If Not, i would like to close this bug

          -Vijay

          Show
          vijaya bhaskar mamidi added a comment - Hi Naveen, Are you seeing the timeouts for 1.1 requests? If Not, i would like to close this bug -Vijay
          Hide
          Leif Hedstrom added a comment -

          Moving out to 3.1.1, until we get a confirmation if this can be closed, or needs more work.

          Show
          Leif Hedstrom added a comment - Moving out to 3.1.1, until we get a confirmation if this can be closed, or needs more work.
          Hide
          Naveen added a comment -

          I've not checked it. With version 3.0, TSFetchURL signature has changed in the header, but the binary has a different signature. It doesn't even compile for me.

          Show
          Naveen added a comment - I've not checked it. With version 3.0, TSFetchURL signature has changed in the header, but the binary has a different signature. It doesn't even compile for me.
          Hide
          Leif Hedstrom added a comment -

          many APIs changed prototypes, but should be an easy fix. There's even a little perl script (tools/apichecker.pl) to help the migration of plugins to 3.0.

          Show
          Leif Hedstrom added a comment - many APIs changed prototypes, but should be an easy fix. There's even a little perl script (tools/apichecker.pl) to help the migration of plugins to 3.0.
          Hide
          Naveen added a comment -

          The prototype change is fine, but they have a different signature from their implementation.

          InkAPI.cc:
          TSFetchUrl(const char* headers, int request_len, unsigned int ip, int port , TSCont contp, TSFetchWakeUpOptions callback_options,TSFetchEvent events)
          ts.h.in:
          tsapi void TSFetchUrl(const char* request,int request_len, struct sockaddr const* addr, TSCont contp, TSFetchWakeUpOptions callback_options,TSFetchEvent event);

          Show
          Naveen added a comment - The prototype change is fine, but they have a different signature from their implementation. InkAPI.cc: TSFetchUrl(const char* headers, int request_len, unsigned int ip, int port , TSCont contp, TSFetchWakeUpOptions callback_options,TSFetchEvent events) ts.h.in: tsapi void TSFetchUrl(const char* request,int request_len, struct sockaddr const* addr, TSCont contp, TSFetchWakeUpOptions callback_options,TSFetchEvent event);
          Hide
          Leif Hedstrom added a comment -

          That seems a bug that must have happened during IPv6 changes. Alan?

          Show
          Leif Hedstrom added a comment - That seems a bug that must have happened during IPv6 changes. Alan?
          Hide
          Leif Hedstrom added a comment -

          I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going.

          Show
          Leif Hedstrom added a comment - I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going.
          Hide
          Leif Hedstrom added a comment -

          Moving out to v3.3.0, move back to 3.1.4 if this will be work on soon.

          Show
          Leif Hedstrom added a comment - Moving out to v3.3.0, move back to 3.1.4 if this will be work on soon .
          Hide
          Leif Hedstrom added a comment -

          Moving to 3.3.2.

          Show
          Leif Hedstrom added a comment - Moving to 3.3.2.
          Show
          Leif Hedstrom added a comment - Moving to 4.2.0 as per https://cwiki.apache.org/confluence/display/TS/New+Release+Processes

            People

            • Assignee:
              Unassigned
              Reporter:
              Naveen
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:

                Development