Wrong status results

@ravanh I see the issue now and tested your link and also got a 404 error. Thank you for clarifying and providing an example. It wasn’t allowing redirects previously. I went ahead and added settings for allowing redirect and changing the max redirects if you want. I tested the link again and it’s returning a 200 status now. I left the max redirects set to 5.

Please update to version 1.1.3.6.

Basically it’s just changing the method from HEAD to GET, so essentially you could have used the hook I gave you in our other thread to do that, though we were looking at using it for a different purpose. I figured this is probably a common issue, so I made it easy an added a setting for it instead of having to hook into it.

Hope that helps! Let me know if you need anything else. Would love a review if you have a moment, too. ??

Ok, I’ll test the new version asap ??

In the meantime: with the HEAD request, why did it not report a 302 response instead of a 404?

I just updated to 1.1.3.7, cleared all results and started a new multi-scan. Sadly, the URL shows up as 404 again…

Did you enable the “Allow Redirects” option in settings?

Did you enable the “Allow Redirects” option in settings?

Ah, no I had not. That did the trick ??

Still, with the option turned off, I’d expect the 302 response to show up in the results instead of a 404. Would it be possible to fix that?

I’ll look into that and let you know. ??

Another example is an embedded image from an external site: https://www.tameteo.com/wimages/fotof8bbd2acf5840e9ed84a6e7602df7ded.png

Visiting that URL in a browser will get a 200 result, and the image shows on our site just fine. But it appears as 404. However, with the Allow redirects, it does show as a 200… would this mean that a HEAD request gets a different response from these external sites?

Here’s the thing. The HEAD method is similar to the GET method but does not retrieve the body of the response—only the headers are returned. Servers may treat HEAD requests differently, especially when redirecting. Some sites might not send a 302 (or other redirect status) for HEAD requests but may send a redirect for GET requests. In particular, not all servers may support HEAD requests the same way as GET requests, and this can lead to different status codes or behavior. The reason we are using the HEAD method by default is because it is faster and more efficient. Using GET loads the content body, thus providing more accurate status codes. If it’s too slow to use the GET method, you could alternatively omit the redirected links so they don’t keep returning false for you.

So you think the HEAD method is indeed the cause here? If so, I’ll keep the Allow redirects option activated.

But would it be possible to show redirected URLs as 30x (even if not broken) in the results? I’d like to keep an eye on those and possible replace them with the end (200) URL, if you know what I mean ??

Yes, the HEAD method is the culprit and I cannot detect if it is a redirect if the site is returning a 404 status code.

As for the GET method, if you change the max redirects to 0, it will show the first status code (30x) instead of the end result (which is usually 200 or 404). Just know that if the page it is redirecting to doesn’t work, you won’t know since you are only capturing the first status code. Unfortunately I can’t show both unless I do two separate requests, which isn’t good for performance.

Note that I realized that the minimum max redirect value was set to 1 in version 1.1.3.7, so I updated that just now and pushed another update. You can update to 1.1.3.8 and then change the max redirects option in settings thereafter.

… ?if you change the max redirects to?0…

Yeah, I tried that but…

Note that I realized that the minimum max redirect value was set to 1 in version 1.1.3.7, so I updated that just now and pushed another update. You can update to 1.1.3.8 and then change the max redirects option in settings thereafter.

Excellent! Many thanks ??

Tried with the new version and setting the max to 0 but then, redirects are not showing up or marked Good when visiting the Results page.

I did a test with a link that redirects twice:

First I set the redirect limit to 1 and the link shows up like:

But if I set the limit to 0 and revisit the Results page:

And on multi-scan it will not show up again…

That’s because multiple redirects do not return a status code between the first and last one. If you increase the number of max redirects to 3 or above, you’ll see that your link shows 200 because that is the final status code. It actually redirects 3 times. So you’ll see a 301 on the first check (with max redirects at 0) and 200 on the last one (with max redirects at 3 or above), and 0 on all of the redirects in between. Does that make sense?

If it’s good, it will not show up on the results or will be removed if it’s on there from a previous check.

So you’ll see a 301 on the first check (with max redirects at 0)

That’s just the thing: If I set to 0, the link will not show up in the results. Only if I set it to 1 (or 2) then it will show up as a Warning (too many redirects).

And if I uncheck the option Allow Redirects, then it will not show up either anymore…

Maybe 0 is interpreted as false somewhere?

I should clarify that the 301 code only shows when it turns to good if it was previously flagged as a warning. 301 codes are considered good, so they won’t show up flagged at all. I will add options to change the types (warning, broken or good) for all status codes.