Submit and vote on feature ideas.

Welcome to the new Parasoft forums! We hope you will enjoy the site and try out some of the new features, like sharing an idea you may have for one of our products or following a category.

Need solution - REST client sends host URI twice

tarunsahu
tarunsahu Posts: 14
edited March 2018 in SOAtest

Does anyone know, why/when does REST client on SOATest send host URI twice ?

For an e.g. - If you look at the Request header for RESTful request, then you should see below:

GET /home HTTP/1.0
Host: google.com

However, I am seeing below in my REST Client -

GET http://google.com/home HTTP/1.0
Host: google.com

This makes SOATest to send an invalid URI for GET calls as -

http://google.com/http://google.com/home

This seems to be something related to proxy setup on SOATest tool and I have tried with all possible options but no luck yet.

Can someone please help here ?

Comments

  • Ireneusz Szmigiel
    Ireneusz Szmigiel Posts: 227 ✭✭✭

    @tarunsahu

    could you, please, post your tst with REST client?

    It looks like configuration issue, but more details allows us help you.

    Ireneusz Szmigiel
    http://www.catb.org/esr/faqs/smart-questions.html

  • tarunsahu
    tarunsahu Posts: 14

    @Ireneusz Szmigiel - Thanks for your response.
    Attached is the sample tst and project file.
    Reinstalled the tool but still no luck..

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭
    edited March 2018

    GET http://google.com/home HTTP/1.0
    Host: google.com

    This type of request is correct/legal and doesn't describe something invalid. An absolute URI is used on the first line when an HTTP proxy is used. This likely means you have SOAtest configured to use an HTTP proxy server. If you configure SOAtest to not send messages through an HTTP proxy server then you will get a relative URI on the first line.

  • tarunsahu
    tarunsahu Posts: 14
    edited March 2018

    Hi, I have verified the proxy setup and there was no change made - I have also reset the proxy settings to match with other machines where the soatest works well with same tst and project file without returning http 404.

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭

    What do you see in the Preferences under Parasoft > Proxy. SOAtest will only send absolute URI in the header if an HTTP proxy is enabled.

  • tarunsahu
    tarunsahu Posts: 14

    "Use system proxy configuration" is enabled but I have tried disabling it as well which also didn't help me.

    Below is the sample request & response header details :

    Request -

    GET <http://localhost:7401/healthcheck HTTP/1.1>
    Host: localhost:7401
    Connection: close

    Response -

    HTTP/1.1 404 Not Found
    Cache-Control: no-cache
    Pragma: no-cache
    Content-Type: text/html; charset=utf-8
    Proxy-Connection: Keep-Alive
    Connection: Keep-Alive
    Content-Length: 2622

    Since, this is a GET request so there is no request Body.

    The same request works on other tools such as Postman, Chrome Rest client, directly on Internet explorer. The issue is just with SOATest.

    I have reinstalled SOATest twice but nothing helped me yet.

  • Matt Love
    Matt Love Posts: 91 admin

    Hi @tarunsahu,

    Could it be that whatever service is providing a healthcheck on port 7401 is running on other machines but not on your localhost?

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭

    My guess is the 404 is unrelated to absolute vs relative URI in the header. HTTP proxy configuration affects this but regardless both ways are legit. The 404 may be correct. That resource is probably non-existent on localhost:7401. If that's the case then you should also get a 404 when visiting that URI in a web browser on the same SOAtest machine.

  • tarunsahu
    tarunsahu Posts: 14

    @Matt Love The service is available on local host. Just before this example, I had shared the sample request for google home page too.

    @benken_parasoft I am always calling a valid, up and running service. I tried calling google services as well, which are always up.