nokia / nokia/corteca-cli

Inconsistencies across various configurations of HTTP listen endpoints

Open
#19 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement invalid
Dominant language
Go
Stars
29
Forks
12
Avg merge
19h 37m
Merged PRs (30d)
2

Description

HTTP listener endpoints are used in three different places in the configuration:

  1. When defining a publish target with method listen
  2. When defining a publish target with method registry-v2
  3. When defining a device type cwmp, in the server field

The addr field in the above cases is interpreted in different ways. For (1) and (3), it is read with url.Parse(), hence it requires a schema prefix as well as a host. For (2) it is passed directly to the http.Server.Addr so it accepts values like <host>:<port> or :port and does not accept schema.

Furthermore, although (1) requires a schema, it does not respect https and does not read the user-provided certificate fields so that it can spawn an https listener.

A common approach must be implemented; a listener should accept only :, in the same way that (2) is currently doing. User-provided certificate data should be respected to spawn TLS enabled https listeners.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the three configuration paths for publish targets using listen and registry-v2, and the cwmp device type's server field; compare their url.Parse() and http.Server.Addr handling. Verify that all paths accept hostname:port values consistently and that the configured certificate data enables TLS listeners when provided.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.