How to escape # character?

Hello, I’m new to Gatling and Scala and am having difficulties using Gatling to test our Vaadin application

Once I have logged in the URL is recorded as http://v217s08r2643:8080/application/#!-

From here I can click on “Search” or “Admin” etc and the URL becomes http://v217s08r2643:8080/application/#!-/search or http://v217s08r2643:8080/application/#!-/admin

If I attempt a get request for any URL containing a #, the system always attempts to get http://v217s08r2643:8080/application/ (it disregards the # character and anything that follows it) so I can never reach the page I am after

I have tried wrapping my URL in triple brackets, or single brakcets with an escape character but nothing seems to work.

As a coding numpty I could really use some help with this.



Your HTTP traffic works as you think it does.

In an URI, everything that comes after a # is an anchor and is NEVER sent from the user-agent to the server (try hitting such an url in your browser and see the actual HTTP call with something like firebug or Chrome Dev Tools).

Tons of frameworks use anchors as markers to be parsed by some javascript code, that could eventually trigger some Ajax calls.

You should use the recorder.



To use raw strings in Scala use triple quotes:

""" http://v217s08r2643:8080/application/#!-/search"""

It may work, just a guess.


I was trying to use a get request as a workaround as my application actually uses websockets.

If I access the application from a web browser I can see that when I login my response is

272|for(;;);[{“syncId”: 3, “changes” : [[“change”,{“pid”:“0”},[“0”,{“id”:“0”,“location”:“http://v217s08r2643:8080/getit/#!-”}]]], “state”:{}, “types”:{“1”:“7”,“0”:“0”}, “hierarchy”:{“1”:[“22”],“0”:[“1”,“2”]}, “rpc” : , “meta” : {}, “resources” : {}, “timings”:[151, 0]}]

Which indicates that my current locations is where I expect to be

If I then send the request

182|{“csrfToken”:"${seckey}", “rpc”:[[“33”,“”,“notifyUriChanged”,[“search”]]], “syncId”:3}

then I expect to see this response (which I do in a browser) indicating that my location has changed

29984|for(;;);[{“syncId”: 4, “changes” : [[“change”,{“pid”:“0”},[“0”,{“id”:“0”,“location”:“http://v217s08r2643:8080/getit/#!-/search”}]],…

Instead I just get the same response back as above

272|for(;;);[{“syncId”: 3, “changes” : [[“change”,{“pid”:“0”},[“0”,{“id”:“0”,“location”:“http://v217s08r2643:8080/getit/#!-”}]]], “state”:{}, “types”:{“1”:“7”,“0”:“0”}, “hierarchy”:{“1”:[“22”],“0”:[“1”,“2”]}, “rpc” : , “meta” : {}, “resources” : {}, “timings”:[151, 0]}]

I was hoping that it was becasue it was’t handling the #'s in URLs, but I guess that’s not the case.

Do you have any suggestions? I’m replicating the browser requests exactly.

Then why don't you use WebSockets?

I am using websockets (with that tutorial) and that’s where my trouble is. I was hoping I could use a simple get request as a workaround but now you’ve told me I can’t do that either.

All I know is that the response I receive when using Gatling is different to the one I receive using a browser with the exact same request.

If I look at my Vaadin logs I can see that it appears to be receiving the request to move to the search screen and the page content is generated but the expected response is never seen in Gatling

So now I’m a little more clued up that you can’t send # to Gatling, I’ll open another topic with what I think is the issue now

No need, I’ve worked it out. It was something simple in the end. The response size of 29984 was too big for the default websocket frame decoder setting. Multiply by four and it works now. Yay!

Great! And good work finding out the solution!

Oh, man! I wish I had known that a long time ago… I always just assumed, I never actually tested.

That means you can’t rely on anchors in order to do traffic source tracing. You have to use query parameters, don’t you. UG. Time to delete my old URLs. :stuck_out_tongue:

Fragments (the actual term) are supposed to define a location within the document, so user-agents are not supposed to send them to the server, but get the resource, and then move to the appropriate location. They don’t account for URI equality.

For a few years, front end frameworks have been using them as a trick to provide additional location information in SPA.