We set Accept-Range on pass, is that OK ?

[bsdphk]

Shouldn't we leave it to the backend to set A-R on pass ?

[nigoroll]

bugwash:

Right now, we add Accept-Range to any 200 response when http_range_support is on. This happens after vcl_deliver, so there is no VCL control over it.

We agree that we want more VCL control and three alternative approaches have been discussed:

• add a switch to vcl if Accept-Range should be added if not present
  • concern: switch-ism
• set Accept-Range before calling vcl_deliver, so it can be removed
  • concern: how would vcl determine where the A-R came from?
• do not set Accept-Range in core code, but rather in builtin.vcl
  • concern: Will this still DTRT for 99.9% of the users?

We agree to handle this as part of #3246

Also we agree that the documentation of http_range_support could be improved.

[nigoroll]

I realized that the actual cause of the problem is that we mixed handling of ranges in core code and the range vdp. By moving all relevant parts to that one, whether or not we send Accept-Ranges can be controlled by having the range vdp active or not.

See #3289

[bsdphk]

How this should work:

1. vcl_backend_deliver{} should be able to set/unset Accept-Ranges as desired.
2. On pass'ed responses, the backend controls if A-R should be in resp.http going into vcl_deliver{}

[nigoroll]

@bsdphk that option was discussed before, see above:

• set Accept-Range before calling vcl_deliver, so it can be removed
  • concern: how would vcl determine where the A-R came from?

How do you address the concern?

[bsdphk]

You can test obj.uncachable if it is true, the header came from the backend.