HTTP_AddCookie

I am intending to make some changes to HTTP_AddCookie which is part of the AcornHTTP module.

Currently the SWI has what I regard as a fault, because the cookie is never persisted on disc, even if an expiry date is explicitly set. (This is a simple matter of a flag not being set in the module. I have reason to think it was not intentional because the call also writes out the cookie store to disc.)

While I am making changes I want to deal with a few other things. There is currently no easy way of deleting a cookie, other than a call to HTTP_AddCookie with the expiry date set to the past. I think it would be nice to offer Max-Age in seconds as an option.

Also, R3 is the only parameter where passing a NULL causes the module to try to read from zero page. With R1, R2, R4 and R5 this is avoided. If any of R1, R2, R4 or R5 are NULL then the call fails silently, as it assumes, wrongly, that malloc has failed through lack of memory. Is this sensible, or should the SWI generate an error.

If any of the parameters R1, R2, R4, R5 are pointers to empty strings, or to things which do not look like a domain, path, name, etc., these are not presently faulted. Should that be improved?

I think I would propose using one of R0 bits 1 to 31 to indicate that R6 contains the Max-Age, in which case R3 would be ignored. Should R6 be a pointer to a Max-Age string, containing the age limit in seconds, or should it be an integer? I’d favour the latter, I think.

I will also be looking into doing other work to support hostname-only cookies and the HttpOnly and SameSite attributes, so some of the undefined flags will go on those. I’ll probably put them into bits 1 to 4, and use bit 31 to indicate that R6 is supplied.

Any comments on this approach?

I have also now discovered that the value in R5, the domain, is expected to be passed with the elements reversed, so “org.riscosopen.www” instead of “www.riscosopen.org”. This seems quite unreasonable! I suspect the only software to have made use of this call was the Phoenix browser, which was a development of Browse implementing Javascript. I wonder whether we could change the API to allow the domain to be passed the right way round?

Janet

Currently the SWI has what I regard as a fault, because the cookie is never persisted on disc, even if an expiry date is explicitly set.

The documentation (Docs.History) says that HTTP_AddCookie “allows you to directly insert a cookie into memory” (my emphasis). This is not mentioned in Docs.SWIs though!

Docs.SWIs gives no documentation beyond a brief statement of what each parameter is. It does not warn about the order of the elements for the domain name. The Acorn URL Fetcher API Specification mentions that AcornHTTP provides cookie management code, but says nothing about it.

After the remark you quoted Docs.History adds “Needed to implement JavaScript”. In other words, the SWI is designed to allow a JavaScript interpreter in a browser to add cookies to the store. In most implementations there is nothing preventing JavaScript from creating a persistent cookie. I think that the fact that HTTP_AddCookie does not allow you to is an oversight, and if Browse had been sufficiently developed to add JavaScript, this fault would have been noticed and corrected.

@druck I am guessing your comment about Janet refers to the fact that addresses on the Joint Academic Network in the UK used to operate the opposite way round, with “uk” first.

I should have explained that internally AcornHTTP reverses the order of the elements in order to more easily maintain a sorted list of domains in a hierarchical order. It makes it easier to find matching domains for sending the cookies on future requests (though there are several bugs in this area of the code). Obviously the cookies come in from the servers with the Domain attribute in the expected order, and the module reverses this before storing. Significantly the module also restores the order to normal when providing access to cookie information via HTTP_EnumerateCookies. So again, I think the order expected by HTTP_AddCookie is at best poor design (and totally undocumented, even in the source) but most likely another oversight that never got picked up because development of Browse ceased around this time.

I would be very interested to know if anyone else has ever used the call, given the lack of documentation. The wiki page I linked to above was written by me a few days ago. The fact that URL_GetURL might return a flag indicating there are cookies to process was also completely undocumented, as far as I know. I think Rick had been aware of it, but I assume he got the information from the source?

I suppose the safest thing to do would be to signal the API change by using another flag bit. That would allow backwards-incompatible changes to be introduced, such as validating the parameters passed and generating errors. At present, although the fetcher code makes sure cookie names contain valid characters, and that domains and paths are sensible, HTTP_AddCookie just takes what it’s given, meaning you could pass domain names containing spaces, cookie names containing equals signs, etc.

I’m tempted just to make the change anyway, without a flag bit, as I doubt any software is really using the call, but I’d appreciate other views on this.

I should have explained that internally AcornHTTP reverses the order of the elements in order to more easily maintain a sorted list of domains in a hierarchical order. It makes it easier to find matching domains

That’s exactly why JANET opted for that ordering, but they switched to the way everyone else was doing it after a while.

I used to have druck@uk.ac.ucl.cs on JANET and druck@ucl-cs.uucp when wandering around other parts.

From what I remember from a networking course many years ago, DNS searches are carried out in the same reverse order – first ask a root server for a list of servers for the top-level domain (uk), then ask the .uk server for .co server, then ask the .co server for the domain and so on.