OTLP receiver with HTTP protocol returns 404 in version 0.29.0

[dgarciarubio]

Describe the bug
The http endpoint for traces logs and metrics returns 404 in 0.29.0

Steps to reproduce
Start a container with the image otel/opentelemetry-collector:0.29.0, with the otlp receiver with http protocol enabled.
Make a post request to any of the endpoints:

• /v1/traces
• /v1/logs
• /v1/metrics

What did you expect to see?
The container should respond with status 200

What did you see instead?
The container responds with status 404

What version did you use?
Version: 0.29.0

What config did you use?
docker-compose.yml:

version: '3.4'
services:
  telemetry.collector.0.28.0:
    image: otel/opentelemetry-collector:0.28.0
    restart: always
    command: ["--config=/etc/otel-collector-config.yml"]
    volumes:
      - ./otel-collector-config.yml:/etc/otel-collector-config.yml:ro
    ports:
      - "65028:55681" #post to this port returns 200
  telemetry.collector.0.29.0:
    image: otel/opentelemetry-collector:0.29.0
    restart: always
    command: ["--config=/etc/otel-collector-config.yml"]
    volumes:
      - ./otel-collector-config.yml:/etc/otel-collector-config.yml:ro
    ports:
      - "65029:55681" #post to this port returns 404

otel-collector-config.yml:

receivers:
  otlp:
    protocols:
      http:
processors:
  batch:
exporters:
  logging:
    loglevel: debug
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [logging]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [logging]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [logging]

Environment
Microsoft Windows 10 Version 21H1 (OS Build 19043.1052)
Docker for Windows Version 3.3.3 (64133), Engine 20.10.6, Compose 1.29.1

[sincejune]

Actually, I don't think it's a bug. According to the documentation, you should add necessary headers to make it work.

The client MUST set "Content-Type: application/x-protobuf" request header when sending binary-encoded Protobuf or "Content-Type: application/json" request header when sending JSON encoded Protobuf payload.

Can you try again with one of the above headers?

[bogdandrutu]

@dgarciarubio indeed we changed the endpoint to return 404 if no Content-Type sent. Can you post the request that you send?

[dgarciarubio]

Yeah, it's definitely the missing header which produced the 404 response. Including it produces the expected behaviour.

Should this be mentioned in the changelog? I think so, because clients should be aware of this new behaviour. Don't know under what category though.

[dgarciarubio]

I'll close the issue, as the behaviour is expected, acording to the documentation.