Forum Discussion

haneef's avatar
haneef
New Contributor
15 years ago

REST Request sending 2 requests for every invocation

Hi,

My REST service is based on Apache Wink and running in Tomcat.

Whenever I send a request via soapUI , it is sending 2 request. One of them doesn't have content type. Any idea why it is sending 2 requests. BTW I'm using soap ui 3.6.1 free version. I tunneled the requests and given below just the headers

First request headers: ( This is correct)

POST /AuditServer/rest/Validator/BatchMessage HTTP/1.1
Connection: close
Content-Type: application/xml
User-Agent: Jakarta Commons-HttpClient/3.1
Host: 127.0.0.1:9080
Content-Length: 2681


Send request header (duplicate request without any content type , but this also sends content body)


POST /AuditServer/rest/Validator/BatchMessage HTTP/1.1
Host: 127.0.0.1:9080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2) Gecko
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
  • Hi,

    Were you able to find a workaround for this? I've come across the same issue (SOAP UI 3.6.1 on WinXP) and it's causing an error on the second invocation (because the endpoint expects POST data, not a GET request, see attached, screenshot from Wireshark). Headers etc are like yours (user agent "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko" and so on), except the second invocation is always a GET. In my case the second invocation returns an error, which is fine because SOAP UI is still "looking" for a response from the POST (which succeeds). However, when I do a burst of 5 simultaneous calls (in a TestSuite where each TestCase calls the same endpoint), SOAP UI will arbitrarily "see" the response from the (failed) GET as the response to the POST and report an error.

    Any help would be much appreciated.

    Lorkus
  • mattmatwork's avatar
    mattmatwork
    Occasional Contributor
    We are also seeing this with certain GET requests in soapui 3.6.1... Very interested in any info that might at least point us to a workaround. Trying to figure out if something in the setup of the resource might be causing it. It is a child resource nested two levels deep.

    There's another post about this, too, so looks like it's not uncommon: viewtopic.php?f=5&t=6454
  • mattmatwork's avatar
    mattmatwork
    Occasional Contributor
    Just found another post about this: viewtopic.php?f=13&t=6427&p=18969&hilit=mozilla&sid=fc4315ab4780cbf19c2472823dbe59d9#p18969

    I noticed that everyone seems to be having the issue with either localhost or 127 hosts with a specific port, usually ending in "80" which I believe is a standard for websphere, which I'm using to test out my app locally. Wondering if others are using Websphere as well.

    After doing a bit more research on my end, it looks like the secondary request is a generic POST request, with the following headers which are very similar to what others are seeing:
    {Accept}:{[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8]}
    {Accept-Charset}:{[ISO-8859-1,utf-8;q=0.7,*;q=0.7]}
    {Accept-Encoding}:{[gzip,deflate]}
    {Accept-Language}:{[en-us,en;q=0.5]}
    {Connection}:{[keep-alive]}
    {Host}:{[localhost:9080]}
    {Keep-Alive}:{[115]}
    {User-Agent}:{[Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2) Gecko]}
  • Thomas_Bonds's avatar
    Thomas_Bonds
    Occasional Contributor
    I'm seeing something very similar. My REST request is a very simple GET method,
    but the first request doesn't have an authorization header, while the second one does.

    I'm using SOAPUI Pro 3.6.1 on a windows server,
    Build dist-118-2010-10-18, Build Date 2010/10/18 15:21

    Other than that very important difference, the requests are the same.
  • Thomas_Bonds's avatar
    Thomas_Bonds
    Occasional Contributor
    One of my coworkers reports that if you check the ‘Authenticate Preemptively’ box under the soapUI HTTP Settings global preferences, this issue goes away.

    Many thanks to my coworker for figuring this out.