Re: [MERGE] RFC-compliant object invalidation behaviour.

On tor, 2008-08-28 at 23:26 +1200, Amos Jeffries wrote:

> > +const char *
> > +urlAbsolute(const HttpRequest * req, const char *relUrl)
> > +{
> > + LOCAL_ARRAY(char, portbuf, 32);
> > + LOCAL_ARRAY(char, urlbuf, MAX_URL);
>
> LOCAL_ARRAY is unfortunately not thread safe. Someone else may argue,
> but I prefer to see them dead.

I have always wanted to see them dead for many reasons.

* On reasonable systems (i.e. most non-dos) the stack is a very suitable
place for temporary allocations.

* Using a static local array as return value will bite you from time to
time even without threading, and is absolutely not thread safe..

> > + char *path, *last_slash;
> > +
> > + if (relUrl == NULL) {
> > + return (NULL);
> > + }
> > + if (req->method.id() == METHOD_CONNECT) {
> > + return (NULL);
> > + }
> > + if (strchr(relUrl, ':') != NULL) {
> > + return (NULL);
>
> Hmm, can relURL not contain the dynamic-part?
> I'd expect those to have ':' sometimes.

CONNECT URLs are a bit special.. but every other absolute URL must have
a scheme:

But relative URLs do not, ever..

> > + }
> > + if (req->protocol == PROTO_URN) {
> > + snprintf(urlbuf, MAX_URL, "urn:%s", req->urlpath.buf());
>
> ?? no hostname or anything but path on URNs?
> Or is that a very badly named field?

URNs is differnt from URLs.. more like news: where the URI identifies a
resource as such and not where that something is located..

urn:isbn:0-596-00162-2

news:a.message_at_id

> Semantics of xstrdup() AFAIK already are that the recipient gets a
> dynamic pointer and responsibility for its destruction.

Yes. xstrdup() is the same as strdup() except that it never returns NULL
and does not accept NULLs...

Related to this xstrndup() is like strndup with the rules above plus
that it always \0 terminates the result.

Regards
Henrik