tool_writeout: add new writeout variable, num_headers

[anio]

It's a draft PR.
This variable gives the number of headers. Currently it just work with disabled redirect because I didn't find out how to reset the header counter while redirect.
And also this variable is not present in JSON-formatted writeout because the JSON handler just works with curl_easy_getinfo.

[dfandrich]

Where might this be useful? Who would want to know the number of headers without knowing their contents, too?

[anio]

I'm using curl to do some sort of mass tests.

This variable may be helpful for example when I'm looking for some caching issues.
Or when I'm looking for routes on a website those are use a different function/server (e.g. proxy_pass)

And also some times it may be helpful to detect soft 404 pages.

p.s. In the next step I will add a new writeout variable to read header value. e.g. %{header[xyz-cache]}.

[bagder]

1. There's no docs for the variable
2. How's it supposed to count amount of headers when one or more redirect are involved?
3. Test 970 needs update too right?

[bagder]

You don't need these braces.

[emilengler]

Why do this later. You can also init at variable creation

[emilengler]

You can also use fputs. I don't think it's necessary to have the printf overhead here

[anio]

You are right, but this is a thing of the past and not changes I made, but I will change it.

[emilengler]

Sorry but I don't know what you mean

[anio]

I mean I didn't wrote fprintf(stream, "%s", .

[emilengler]

Still something you can change :-)

[anio]

1. There's no docs for the variable

I will write soon.

2. How's it supposed to count amount of headers when one or more redirect are involved?

I think same as http_code we should just count the last response header count. I don't know how to do that.

3. Test 970 needs update too right?

Yes, after updating the JSON response to include header_count. I should update tool_writeout_json. As I mentioned before, it currently just works with curl_easy_getinfo.

[bagder]

I don't know how to do that.

You get an "empty" header last, don't you? That means the end of the headers for this response.

[anio]

You get an "empty" header last, don't you? That means the end of the headers for this response.

Right, but how it can help when I don't know about previous responses? Do I need to count redirects?

[bagder]

Shouldn't you just clear the counter when you get a new set of headers after a previous empty header? That way you'd always count only the last set.

[deepcode-ci-bot]

Congratulations 🎉. DeepCode analyzed your code in 0.318 seconds and we found no issues. Enjoy a moment of no bugs ☀️.

👉 View analysis in DeepCode’s Dashboard | Configure the bot

[bagder]

Looks fine! How about adding a test with a redirect as well just to make sure it does the right thing then as well?

[bagder]

I suggest:: "The number of response headers in the most recent request (restarted at each redirect)"

Should this mention that it doesn't include the first status line?

[anio]

Should this mention that it doesn't include the first status line?

I think it's not necessary when we are talking about headers.

[bagder]

I've just learned that some users think of that as a (special) header too.

[anio]

Oops!
By mentioning this, we also have to mention: the status line which includes the status code and reason message IS NOT a header.

So, do you prefer to mention?

[jzakrzewski]

I'd prefer to mention it because, as @bagder said, some treat the status line as header line (why???).
If we can be clear on the subject, that we should be.

[anio]

OK. So, @bagder, what is your opinion?

[bagder]

Being clear is good, which is why I brought this up to begin with.

[anio]

OK, please give me a good sentence to add.

[jzakrzewski]

Maybe like:
"The number of response headers in the most recent request (restarted at each redirect). Note that the status line IS NOT a header."

[anio]

Thanks! Added.

[bagder]

Thanks!