Advertise version string in the response

[ibnesayeed]

I think it will be useful to expose the engine name and the version string in the response header as well as in the generated HTML. WordPress exposes this information in HTML element, while Drupal exposes his information in HTML element as well as the response header. OpenWayback too should add an HTTP header like this:

X-Generator: OpenWayback-2.2.0

And a meta element like this:

<meta name="Generator" content="OpenWayback-2.2.0" />

Also, it may be a good idea to expose the header in Access-Control-Allow-Headers for CORS.

This provision will allow various tools (such as Memento Aggregator) to automatically predict what to expect from a Wayback server.

[kris-sigur]

I wonder if "Generator" is the right term (I couldn't immediately find a spec for X-Generator).

[anjackson]

I've come across X-Generator, but X-Powered-By is more common. However, perhaps we should use Server as that's standardised?

[kris-sigur]

There is already use of X-Archive- headers in OpenWayback. Perhaps build on that?

X-Archive-Server: OpenWayback/2.2.0

[bitzl]

Just checked, Server is already used by Apache Tomcat. Both X-Powered-By as a general field (potentially denoting everything involved) and X-Generator (mostly CMS systems?) would make sense.

However, I'd favor a more specific header denoting OpenWayback's role as a software in the archiving context, separating it from general server software like Tomcat, JBoss or Apache. So X-Archive-Server would be fine.

When choosing names for header fields, RFC6648 suggests the omission of X- as best practice, as header fields might become standard.

[ibnesayeed]

I am not after any specific name as long as this information is somehow surfaced under any agreed upon name. However it turns out that HTML5 recognized the potential of generator metadata name and standardized it. It is widely being used by WordPress, Drupal, and even Blogger.

As far as HTTP header is concerned, Server header is more suited for web server software such as Apache, Tomcat, Nginx etc. X-Powered-By non-standard header on the other hand is commonly used to convey the programming language or framework (ASP.Net and PHP are known to add this header unless turned off). X-Generator header is widely used by Drupal and in my opinion the reason why they chose that name is to establish parity between the HTML metadata counterpart. I don't know any other application using it on scale though.

I know it is discouraged to used X- prefix in headers because once the name gets popular and a non-prefixed name is standardized, it becomes very hard to go and fix all the tools that were using the prefixed version of the name, same is the case with CSS vendor prefixes. However not adding X- prefix conveys the message that the name is already standard. Reminds me of a rabbit hole!

[ibnesayeed]

I would agree with @bitzl on omission of the X- prefix as the referenced RFC is fairly fresh.

[kris-sigur]

I think it makes sense to be consistent with the existing header extensions. Currently, they all use an X-Archive- prefix. If we don't want to have an X-, then we should consider modifying all the current X-Archive- headers.

Which brings the questions:

1. Is anyone relying on the existing X-Archive- headers?
2. Is anyone else using X-Archive- headers (e.g. pywb)

If no on both counts, we should probably find a new prefix and write up a short "standards" doc for these headers so that others can implement them consistently.

Otherwise, it may be best to stay with the X-Archive- prefix.

[ibnesayeed]

X-Archive-Server looks good to me, which can lead to an immediate implementation. On the HTML side though I think, using HTML5 standard generator meta name will be a good choice.

However in appreciation of the RFC 6648, we can defer the decision to change all X-Archive-* headers to something else in Wayback 3.x. We might want to discuss about that in relevant IIPC working group discussion lists as well as in Memento-dev list to know how much these headers have been utilized. If I remember correctly, during the IIPCGA15 this topic was raised that we should do a better job of surfacing the metadata that is available in X-Archive-Orig-* headers in the replay system. And while we are on this topic, here is a very relevant recent post from the WS-DL blog.

[anjackson]

Given that that potentially involves futzing about with the header of a re-written page, I'd rather not use the generator tag. Apart from anything else, the page handed back might not be HTML5.

[ibnesayeed]

@anjackson I did not mean to modify the replayed page, when I suggested that meta name, I only had entry point and listing pages in my mind such as calendar or table view pages. Now I realized that it's not super useful and people might customize those pages anyway. Although the relevant HTTP header can be present in almost all the responses unless explicitly turned off.

[anjackson]

@ibnesayeed ah, fair enough. No problem with inclusion in the default UI templates.