With the introduction of javAPRSSrvr 3.15b01 (August 2009), two new port types
were added for APRS-IS connected trackers, weather stations, and other send-only
APRS clients to connect to. These ports, HTTP and UDP, provide a mechanism
for the client to send a single packet of information to the server for relay to
the rest of APRS-IS (or equivalent network). The format of this data is
shown below. The server sysops have settled on port 8080 for both HTTP and
UDP support per the IANA alternate HTTP port reservation. Before assuming
the server you use supports these ports, visit their status page (usually
http://server-address:14501) and
examine their port table. I have opened port 8080 for HTTP, WS, and UDP at
srvr.aprs-is.net for testing and uploads to APRS-IS. I have recently opened port 8888 at ametx.com for
secure (HTTPS and WSS) connections. As of javAPRSSrvr 4.3.4, all HTTP/HTTPS ports support status pages, send-only POST/PUT, and WebSockets.
javAPRSSrvr now supports HTTP port functionality on the status port (usually port 14501). Check the status page to determine if the
sysop has turned this functionality on (port availability table).
The HTTP port accepts a single POST request from the client. The post
request must be properly formatted and have a minimum these properties:
- Accept-Type: text/plain
- Content-Type: application/octet-stream
- Content-Length: length of data
HTTP Authentication (javAPRSSrvr Only)
With the release of javAPRSSrvr 4.3.2b76, the HTTP port now properly implements RFC 7235, HTTP 1.1 Authentication Framework.
To do this, a new authorization type (as permitted in RFC 7235) was created called APRS-IS and the
HTTP port now supports the addition of the following header in lieu of including the login line in the content.
Authorization: APRS-IS Base64-encoded-login-line
With this new feature added to javAPRSSrvr, it also supports Base64 encoding of the login line in any connection stream.
Base64 encoding is not secure and should be used with HTTPS connections if security is required.
javAPRSSrvr 4.3.3b40 and later now supports Basic authentication per RFC 7617. The user ID is the callsign-SSID and the password is the APRS-IS passcode for that callsign.
Since no filter can be set, this authentication type is primarily intended for send-only HTTP where the body only contains one or more packets.
An automated weather station, for instance, can use a simple HTTP POST with Basic authentication to send a single packet via a send-only HTTP port.
Send-only data format
The HTTP content consists of at least 1 line: the user login line (see Connecting to APRS-IS) (optional/ignored if
Authorization header is used) followed by one or more APRS "packet" in TNC2 format.
The UDP packet consists solely of the user login line followed by the APRS "packet" in TNC2 format.
All packets will use either the qAO or qAo construct as these are send-only ports. Example:
user TEST-1 pass -1 vers TestSoftware 1.0
TEST-1>APRS,TCPIP*:>This is a test packet
In the above case, the packet will not be accepted on APRS-IS because the login is not
verified (invalid passcode).
The APRS packet may be terminated
with a carriage return, a line feed, or both, or no terminator if it is the last packet. There is
no confirmation of receipt on the UDP packet. javAPRSSrvr responds
properly with an HTTP status response on the HTTP port. HTTP content may be encoded using GZip compression (indicated in the Content-Encoding: gzip header).
HTTP Response Codes
| Code | Description |
| Global |
|---|
| 405 | Only HEAD, GET, POST, or PUT methods supported. |
| Status Page (or associated files such as favicon.ico) |
|---|
| 200 | Valid status page request (including favicon.ico and any other sysop-designated files). |
| 304 | File not modified (only sent for files if if-modified-since in request, status page is always new). |
| 404 | Unknown file/page. |
| WebSocket |
|---|
| 101 | Websocket protocol switchover
If Authorization header used, may include Authentication-Info header |
| 401 | Invalid Authorization scheme or data.
Includes WWW-Authenticate header (see above). |
| 426 | WebSocket upgrade failed |
| Send-only (POST/PUT) |
|---|
| 204 | Valid login and packet(s) sent
If Authorization header used, will include Authentication-Info header with login=verified
X-Packetsrcvd header indicates number of packets successfully passed into server
|
| 400 | No packets parsed/received in content. |
| 401 | Invalid Authorization scheme or data.
Includes WWW-Authenticate header (see above). |
| 403 | Invalid passcode. |
| 409 | User already logged into this server. |
| 411 | Content-length missing or < 8 |
| 413 | Content-length > 8192 |
| 415 | Content-type not application/octet-stream |
| 417 | Content-length not equal to length of data received |
A UDP port may be configured for local direct insertion of packets restricted by firewalls/local IP addresses.
A packet inserted via a local UDP port will use the U indicator in the q construct (qAU).