Jump to content
Al_Nafuur

Redesign PlusROM request HTTP header

Recommended Posts

Currently, the PlusROM functions use the HTTP header "PlusStore-ID" for their requests to their backends.

 

This header should actually only be used for the communication of the PlusCarts with the PlusStore.
Since emulators should also communicate with the PlusROM backends (but not with the PlusStore!), a different header should be used for PlusROM communication.

 

The information to be transmitted to the PlusROM backend with this header field is:

  • device type (0 = Unknown, 1= PlusCart, 2 = Gopher2600, 3 = Javatari.js, 4 = Stella, ..).
  • version
  • unique device ID
  • nickname (this is not necessarily a unique username) 

 

My suggestion is to use the HTTP header "PlusROM-Info". And separate the data with a "|".

e.g.

PlusROM-Info: 1|v2.1.1|0123456789ABCDEF0123456789ABCDEF|Al_Nafuur


However, because there are already some devices and emulators that still send their data to the PlusROM backends according to the previous standard, the backends must be able to distinguish between the two versions.

 

any thoughts or suggestions @JetSetIlly, @DirtyHairy, @Thomas Jentzsch, @Andrew Davie or anyone else?

 

Share this post


Link to post
Share on other sites
Posted (edited)

Suggestions:

  • Use a string to identify the emulator or device, not an enum, and include the version there: "Stella 6.4.1", "6502.ts 1.0.5", etc. That allows to interpret the header without looking at at table
  • Use an UUID for the random ID, that's a standard, and there are packages to generate them
  • Place some reasonable limits on the nickname, i.e. [0-9a-zA-Z ]{0,32}. That allows for straightforward validation and avoids encoding and escaping headaches
  • I would prefer key-value pairs separated by semicolons, trailing and leading spaces trimmed for keys and values, similar to the encoding used for cookies. This makes extending the header in the future much easier

My suggestion would look like this:

PlusROM-Info: platform=Stella 6.4.1; id=4FDFDFC6-0D45-45E0-9045-A2891E2D7493; nick=DirtyHairy

 

Edited by DirtyHairy
  • Like 1

Share this post


Link to post
Share on other sites
18 minutes ago, DirtyHairy said:

Suggestions:

  • Use a string to identify the emulator or device, not an enum, and include the version there: "Stella 6.4.1", "6502.ts 1.0.5", etc. That allows to interpret the header without looking at at table
  • Use an UUID for the random ID, that's a standard, and there are packages to generate them
  • Place some reasonable limits on the nickname, i.e. [0-9a-zA-Z ]{0,32}. That allows for straightforward validation and avoids encoding and escaping headaches
  • I would prefer key-value pairs separated by semicolons, trailing and leading spaces trimmed for keys and values, similar to the encoding used for cookies. This makes extending the header in the future much easier

My suggestion would look like this:

PlusROM-Info: platform=Stella 6.4.1; id=4FDFDFC6-0D45-45E0-9045-A2891E2D7493; nick=DirtyHairy

 

I would agree with this. My only reservation is how the version number of the platform is encoded. Personally, I would advocate a separate "version" field.

  • Like 2

Share this post


Link to post
Share on other sites
Posted (edited)
7 minutes ago, JetSetIlly said:

I would agree with this. My only reservation is how the version number of the platform is encoded. Personally, I would advocate a separate "version" field.

On third thought, I agree 😏 To put this into code

PlusROM-Info: platform=Stella; platform-version=6.4.1; id=4FDFDFC6-0D45-45E0-9045-A2891E2D7493; nick=DirtyHairy

 

Edited by DirtyHairy

Share this post


Link to post
Share on other sites

 

2 hours ago, DirtyHairy said:

Suggestions:

  • Use a string to identify the emulator or device, not an enum, and include the version there: "Stella 6.4.1", "6502.ts 1.0.5", etc. That allows to interpret the header without looking at at table
2 hours ago, JetSetIlly said:

I would agree with this. My only reservation is how the version number of the platform is encoded. Personally, I would advocate a separate "version" field.

👍

 

2 hours ago, DirtyHairy said:
  • Use an UUID for the random ID, that's a standard, and there are packages to generate them

I thought of using GUID/UUIDs too, but without the unnecessary hyphens.

 

2 hours ago, DirtyHairy said:
  • Place some reasonable limits on the nickname, i.e. [0-9a-zA-Z ]{0,32}. That allows for straightforward validation and avoids encoding and escaping headaches

👍

except for the 32 chars I think 16 should be enough for a nick. And maybe add [_] too, otherwise my nick would be invalid 🙂

 

2 hours ago, DirtyHairy said:
  • I would prefer key-value pairs separated by semicolons, trailing and leading spaces trimmed for keys and values, similar to the encoding used for cookies. This makes extending the header in the future much easier

I am a great fan of using existing standards too.

 

 

2 hours ago, DirtyHairy said:

On third thought, I agree 😏 To put this into code

PlusROM-Info: platform=Stella; platform-version=6.4.1; id=4FDFDFC6-0D45-45E0-9045-A2891E2D7493; nick=DirtyHairy

 

This looks nice and is human readable (even if it doesn't need to be).

 

But there is one more thing I would like to mention.

 

Using tcp and http in "gaming" is already a disadvantage, so I want to keep these requests as small as possible to minimize tcp packages and to stay way below the standard MTU size of 1500 bytes (1460 or 1448 bytes payload). Some network connections can have smaller MTU sizes.

 

The proposed changes would not necessarily exceed this limit. But I would still like to shorten/change a few things:

PlusROM-Info: agent=Stella; ver=6.4.1; id=0123456789ABCDEF0123456789ABCDEF; nick=Al_Nafuur

 

 

 

 

 

Share this post


Link to post
Share on other sites
5 minutes ago, Al_Nafuur said:

The proposed changes would not necessarily exceed this limit. But I would still like to shorten/change a few things:

PlusROM-Info: agent=Stella; ver=6.4.1; id=0123456789ABCDEF0123456789ABCDEF; nick=Al_Nafuur

 

I like that.

Share this post


Link to post
Share on other sites
Posted (edited)
28 minutes ago, Al_Nafuur said:

The proposed changes would not necessarily exceed this limit. But I would still like to shorten/change a few things:

Why? To me that sounds like unnecessary optimization. If the packet fragments, so what? Besides, the request size will still be way below the MTU. Using an ESP connected via serial to an Atari 2600 already excludes high performance communication 😛

 

EDIT: Besides, now that I rethink this, an HTTP request larger than the MTU will not usually cause fragmentation at the IP level. Instead, afaik,socket transmissions that exceed the MTU will be split by the network stack into multiple IP packets that fit the lowest MTU on the path.

Edited by DirtyHairy

Share this post


Link to post
Share on other sites
9 hours ago, DirtyHairy said:

[0-9a-zA-Z ]{0,32}

IMO we should require a minimum length (2 or 3). A few more chars (if feasible) would be nice.

Share this post


Link to post
Share on other sites
On 8/31/2021 at 10:31 PM, Thomas Jentzsch said:

IMO we should require a minimum length (2 or 3). A few more chars (if feasible) would be nice.

Some users may not want to be "registered". Also there are currently 55% of the PlusCarts not connected to a PlusStore account and so their PlusStore-Id cannot be resolved to a username

 

Share this post


Link to post
Share on other sites

Ok, but if they decide to register, IMO a minimum length should be enforced.

Share this post


Link to post
Share on other sites
1 hour ago, Thomas Jentzsch said:

Ok, but if they decide to register, IMO a minimum length should be enforced.

The minimum length for a username in nextcloud is 1 char. So a PlusCart that is connected to a PlusStore account will send at least 1 char.

 

Share this post


Link to post
Share on other sites

That should be the rule for emulators then too, IMO.

Share this post


Link to post
Share on other sites

Just don't include the nick field if someone has not registered. Otherwise, let's take the 1 char minimum then.

Share this post


Link to post
Share on other sites

Hm, you mean we should submit scores without registration? @Al_Nafuur what do you think?

Share this post


Link to post
Share on other sites
18 minutes ago, Thomas Jentzsch said:

Hm, you mean we should submit scores without registration? @Al_Nafuur what do you think?

That's what we are already doing.

 

At the PlusROM High Score Club these emulator accounts or PlusCarts are listed as "unknown Emulator user xyz" and "unknown PlusCart user xyz".

 

The numbers are determine by the PlusCart device id, if the device id cannot be resolved via the open API. For Emulators these number is determined by the device id and nickname.

 

Emulator nicknames are not unique (unlike PlusStore usernames), so they are listed with a number determined by the device id too. E.g. "Al_Nafuur emulator user 17" is my firefox javatari.js account  "Al_Nafuur emulator user 120" is my gopher2600 installation account.

 

How these numbers and entries are generated from the device id and/or nickname (if given) is totally up to the PlusROM backends. 

 

The C.A.V.E. Apocalypse backend does not generates any user names. You just need to connect your emulator device id (or PlusCart device hash) with your C.A.V.E. Apocalypse Level Editor account to play your private levels.

 

 

 

Share this post


Link to post
Share on other sites

@Al_Nafuur Are you going to switch? We are currently finalizing Pluscart support in Stella, and I wonder whether I keep the old header or send new one 😏

Share this post


Link to post
Share on other sites

Either way, the PlusROM backends must be able to understand old and new headers. So if we can agree on one variant for the new header, I could add the new header to the backends I host (as far as I know, no one has created their own PlusROM with a backend yet).

 

Share this post


Link to post
Share on other sites
2 minutes ago, Al_Nafuur said:

Either way, the PlusROM backends must be able to understand old and new headers. So if we can agree on one variant for the new header, I could add the new header to the backends I host (as far as I know, no one has created their own PlusROM with a backend yet).

 

I think your most recent suggestion is fine.

Share this post


Link to post
Share on other sites
1 minute ago, JetSetIlly said:

I think your most recent suggestion is fine.

There is one more thing I stumbled across when I starred at some of the backends. The Browser based emulators need a CORS header, so the browser won't ignore/hide the response from the application. Currently the backends can determined this by the "WE" prefix of the generated device-id. With our new header they would have to determine this by the "agent" string.

 

 

Share this post


Link to post
Share on other sites
2 hours ago, Al_Nafuur said:

There is one more thing I stumbled across when I starred at some of the backends. The Browser based emulators need a CORS header, so the browser won't ignore/hide the response from the application. Currently the backends can determined this by the "WE" prefix of the generated device-id. With our new header they would have to determine this by the "agent" string.

 

 

Why? The CORS standard defines Origin for that: if the client sends Origin, you answer with Acces-Control-Allow-Origin. If there ist no Origin header in the request you can omit it.

 

However, you are doing POST with a custom header, and I would expect  that this implies a preflight OPTION request from the server that you have to answer with Access-Control-Allow-Origin and Acces-Control-Allow-Headers (in order to whitelist the header).

 

You shouldn‘t have to worry about this yourself though, most web framework can handle CORS if configured for it.

Edited by DirtyHairy

Share this post


Link to post
Share on other sites
1 hour ago, DirtyHairy said:

Why? The CORS standard defines Origin for that: if the client sends Origin, you answer with Acces-Control-Allow-Origin. If there ist no Origin header in the request you can omit it.

👍

 

1 hour ago, DirtyHairy said:

However, you are doing POST with a custom header, and I would expect  that this implies a preflight OPTION request from the server that you have to answer with Access-Control-Allow-Origin and Acces-Control-Allow-Headers (in order to whitelist the header).

Yes right, (but the preflight requests are sent from the browser)

 

1 hour ago, DirtyHairy said:

You shouldn‘t have to worry about this yourself though, most web framework can handle CORS if configured for it.

most of the PlusROM backends i have built so far were actually only meant as PoC and don't use any special web framworks..

 

I will start tomorrow to extend these to the new headers and will give feedback here.

Share this post


Link to post
Share on other sites
5 hours ago, Al_Nafuur said:

Yes right, (but the preflight requests are sent from the browser)

Ups, sorry, typo, "browser" is what I wanted to write 😏

Share this post


Link to post
Share on other sites
19 hours ago, Al_Nafuur said:

most of the PlusROM backends i have built so far were actually only meant as PoC and don't use any special web framworks..

 

I will start tomorrow to extend these to the new headers and will give feedback here.

The backends of the following PlusROMs should now work with the new header too:

  • all High-Score-Club games
  • PlusClock
  • bB-painter
  • bB-maps
  • online combat
  • t-online newsticker ( this backend doesn't work currently because of a bug in the news API)

these PlusROM backends still have to be extended:

  • C.A.V.E. Apocalypse
  • Sokoboo Plus

 

Share this post


Link to post
Share on other sites

The C.A.V.E. Apocalypse backend is now adapted to cope with the new headers too.

 


 

 

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...