Ask a Question

When verifing links with hash (#) in url, XmlHttpRequest object always returns 400 BAD REQUEST

bb1832j
Occasional Contributor

When verifing links with hash (#) in url, XmlHttpRequest object always returns 400 BAD REQUEST

Hello,
I am trying to verify the links on a web page using the XmlHttpRequest object.  When I check a url that
has the hash (#) symbol in the address I always get a "400 BAD REQUEST" status, even for links I know
are valid.  Is there a way to work around this issue?

Thanks.

11 REPLIES 11
cunderw
Community Hero

Re: When verifing links with hash (#) in url, XmlHttpRequest object always returns 400 BAD REQUEST

A 400 means that the request was malformed. In other words, the data stream sent by the client to the server didn't follow the rules.

 

# in a url is called an anchor link, and it's how your browser knows where in the page to position you. It is not a correct endpoint to send a request to. So in a nut shell you're trying to send a request to something that doesn't actually exist. 

 

Use you're browsers dev tools to watch the network requests when you click one of the links. It will striped out the anchor tags.

 

The only work around would be to removing anything after the #, but more than likely you would just be sending the same request over and over at that point. 

 

What is your end goal here? If you're wanting to test APIs and end points then you should look at something like ReadyAPI. 

 

If you actually want to verify the UI and clicking links takes you to the correct place, then XmlHttpRequest isn't the approach I would use. I would actually click the link and validate the correct page / position loads.


Thanks,
Carson

Click the Accept as Solution button if my answer has helped
tristaanogre
Community Hero

Re: When verifing links with hash (#) in url, XmlHttpRequest object always returns 400 BAD REQUEST

Oh, crud... you know, @LinoTadros demonstrated a way of using an Attributes checkpoint to do this kind of thing without actually doing any navigation.  I'll need to go back and check my notes from Connect 2017 but it was a pretty cool way of validating links on a page. Anyone else remember that? @Marsha_R?


Robert Martin
[Hall of Fame]
Please consider giving a Kudo if I write good stuff
----

Why automate?  I do automated testing because there's only so much a human being can do and remain healthy.  Sleep is a requirement.  So, while people sleep, automation that I create does what I've described above in order to make sure that nothing gets past the final defense of the testing group.
I love good food, good books, good friends, and good fun.

Mysterious Gremlin Master
Vegas Thrill Rider
Extensions available
cunderw
Community Hero

Re: When verifing links with hash (#) in url, XmlHttpRequest object always returns 400 BAD REQUEST

I think the example @LinoTadros was using may have just been verifying that all the links are present using NativeWebObject's find method to find everything that was a link. If I'm understanding correctly @bb1832j wants to verify the link has a successful response. 


Thanks,
Carson

Click the Accept as Solution button if my answer has helped
tristaanogre
Community Hero

Re: When verifing links with hash (#) in url, XmlHttpRequest object always returns 400 BAD REQUEST

No, he did something that actually checked to make sure that there was a valid response... wish I could remember what it was... 


Robert Martin
[Hall of Fame]
Please consider giving a Kudo if I write good stuff
----

Why automate?  I do automated testing because there's only so much a human being can do and remain healthy.  Sleep is a requirement.  So, while people sleep, automation that I create does what I've described above in order to make sure that nothing gets past the final defense of the testing group.
I love good food, good books, good friends, and good fun.

Mysterious Gremlin Master
Vegas Thrill Rider
Extensions available
Marsha_R
Community Hero

Re: When verifing links with hash (#) in url, XmlHttpRequest object always returns 400 BAD REQUEST

My notes say:

Web comparison checkpoint only checks HTML. If content changes, it will still pass.

Web accessibility checkpoint - 5 way compliance - see checkboxes

 

https://support.smartbear.com/testcomplete/docs/testing-with/checkpoints/web-accessibility/about.htm...

tristaanogre
Community Hero

Re: When verifing links with hash (#) in url, XmlHttpRequest object always returns 400 BAD REQUEST

Right.... if you do a web accessibility checkpoint and only select the links, it doesn't just check to make sure the link is there, it actually does a behind the scenes check to make sure that the link actually references a correct URL.... give it a try.


Robert Martin
[Hall of Fame]
Please consider giving a Kudo if I write good stuff
----

Why automate?  I do automated testing because there's only so much a human being can do and remain healthy.  Sleep is a requirement.  So, while people sleep, automation that I create does what I've described above in order to make sure that nothing gets past the final defense of the testing group.
I love good food, good books, good friends, and good fun.

Mysterious Gremlin Master
Vegas Thrill Rider
Extensions available
bb1832j
Occasional Contributor

Re: When verifing links with hash (#) in url, XmlHttpRequest object always returns 400 BAD REQUEST

I did try to use the WebTesting.WebAccessibility.Check() method.  The page I tested had several links intentionally broken.  The method still returned all links as passed.  With the XmlHttpRequest object, I am able to see the status message and that the broken links were found.

Marsha_R
Community Hero

Re: When verifing links with hash (#) in url, XmlHttpRequest object always returns 400 BAD REQUEST

bb1832j
Occasional Contributor

Re: When verifing links with hash (#) in url, XmlHttpRequest object always returns 400 BAD REQUEST

Yes I do...

SmartBearPic1.PNG

cancel
Showing results for 
Search instead for 
Did you mean: