plgd-dev / go-coap

From my understanding of the RFC ETags are optional: https://datatracker.ietf.org/doc/html/rfc7252#section-5.10.6

However, in go-coap they are always included as there is a fallback, potentially increasing the response message size needlessly:

go-coap/udp/client/responsewriter.go

Lines 47 to 53 in 4d46680

    
           if !r.response.HasOption(message.ETag) { 
        
           	etag, err := message.GetETag(d) 
        
           	if err != nil { 
        
           		return err 
        
           	} 
        
           	r.response.SetOptionBytes(message.ETag, etag) 
        
           }

For the endpoints that I use ETags with, I calculate them using the hashstructure library (before encoding and compressing the payload). For all other endpoints I don't use ETags, and I have other means of verifying the integrity of the payload (gzip's CRC32 checksum).

Would it make sense to add a boolean option to the server deciding whether to automatically calculate checksums for ETags, or better yet, include an option to set an ETag generator as an option (nullable/pointer or with a "no-op" generator for those that don't want it). This way, the library users can choose not to auto-generate ETags, and if they auto-generate them, they can choose how to do so (everyone might not want to use CRC64)?

Sounds reasonable to me. I think allowing the user to optionally add a custom ETag generator is a useful extension of functionality. @jkralik what do you think?

@Danielius1922 I agree. We can create option to the server that allows to set function - etag generator. And nil will be means that etag option will be not set by server/client.

I have a related question (less advanced):

I implemented a go server with endpoints that are written similar to the handleA endpoint in:
https://github.com/plgd-dev/go-coap/tree/master/examples/simple/server

With w.SetResponse(codes.Content, message.TextPlain, bytes.NewReader([]byte("hello world"))) it automatically sets options which look like:
"options": [
"ETag(etag=00 00 90 62 7E 81 4E 6E",
"Content-Format: text/plain; charset=utf-8"
]

Since I don't need any Options to be sent, I worked with
w.SetResponse(codes.Content, message.TextPlain, bytes.NewReader([]byte("hello world")), message.Option{make([]byte,0), 4})
it sets e.g. only the Etag to 0. But there is still an Etag in the options.

Is it possible not to send any options at all?

Is it possible not to send any options at all?

Yes. Just follow the code in example:

go-coap/examples/simple/server/main.go

Line 28 in e59fa91

func handleB(w mux.ResponseWriter, r *mux.Message) {

This is addressed in github.com/plgd-dev/go-coap/v3. ETag could be set via options:

https://github.com/plgd-dev/go-coap/blob/master/net/responsewriter/responseWriter.go#L41

I will close it. Feel free to reopen it. Thx

	if !r.response.HasOption(message.ETag) {
	etag, err := message.GetETag(d)
	if err != nil {
	return err
	}
	r.response.SetOptionBytes(message.ETag, etag)
	}

Optional ETags in response from server?