src: introduce http_parser_url_init

[indutny]

The struct must be zero-initialized, but this wasn't explicitly stated
anywhere in headers. Introduce http_parser_url_init API method that
will do it.

Fix#209

cc @bnoordhuis

[jay]

My pr at #222 is more comprehensive, I'm not sure why you closed it as unnecessary. I added the parameter checking and zeroed the structure. In http_parse_host there's no point continuing without the host field and in http_parser_parse_url there's no point calling the former without the host field. Also something should be done to make sure that the buflen isn't greater than max uint16_t, which I covered in both.

Also it occurs to me now an overflow check is also due for size_t buflen assignment in http_parse_host since there's no guarantee size_t is greater than uint16_t (although it's extremely likely), which would probably look something like this, placed immediately after the assignment:

if(buflen<u->field_data[UF_HOST].off) { // overflowreturn1;
}

[indutny]

It won't call it without host field, because UF_HOST won't be set. In case of test string it is doing a right thing and treating test as a schema, and then awaits for the hostname.

[jay]

In the case a schema field was found but a host field was not then http_parser_parse_url will still call http_parse_host. I changed that by failing if a schema field is found without a host field and calling http_parse_host only if a host field was found as seen here.

[indutny]

Right and http_parse_host is called because it is what is expected after the scheme. It is intentionally invoked for this thing to fail. Practically, is there any difference in behavior your PR and current implementation (in master branch)?

[jay]

Yes it's different. The current implementation is calling http_parse_host when UF_HOST is not set which contradicts what you said earlier. Whether that's correct or not you would know having more familiarity with the code base, however I did not think that was correct.

[indutny]

Right, I was wrong about it. Sorry. However, except this I don't see any behavior difference.

[indutny]

@mscdex may I ask you to review it? ;)

[jasnell]

@indutny@mscdex ... any further thoughts on this one?

[mscdex]

LGTM

[jasnell]

Landed in 777ba4e