View Issue Details

IDProjectCategoryView StatusLast Update
000955610000-004: ServicesSpecpublic2024-06-10 17:09
ReporterJim Luth Assigned ToMatthias Damm  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version1.03 
Fixed in Version1.05.04 RC1 
Summary0009556: No error code identified to limit size on server side of response message to be sent
Description

Hello,

In TCPUA protocol and sessions services each peer (client/server) might declare a maximum size for OPC UA message it will accept to receive.
There is no revision of those parameters, i.e. MaxMessageSize/MaxChunkCount in HEL/ACK and maxResponse/maxRequest
MessageSize, which means it is not possible to declare we will limit size when encoding message to be sent to the other peer.
However it seems not reasonable to accept unlimited or too large sizes for availability and even security issues (memory limits, etc.).
There is no clear indication on how to deal with message to be sent in the specification whereas it is described for message received, the following status code seem only meant to be used in reception:

  1. "Bad_RequestTooLarge: The request message size exceeds limits set by the server." (v1.03, part 4, table 172)
  2. "Bad_ResponseTooLarge: The response message size exceeds limits set by the client." (v1.03, part 4, table 172)
  3. "Bad_EncodingLimitsExceeded: The message encoding/decoding limits imposed by the Communication Stack have
    been exceeded." (v1.03, part 4, table 172)
  4. "TcpMessageTooLarge: The size of the Message specified in the header is too large.
    The Server returns this error if the Message size exceeds its maximum buffer size or the receive buffer size negotiated during the Hello/Acknowledge exchange.` (v1.03, part 6, table 38)

Status codes 1. and 2. indicates explicitly that it means to be used for the peer limit (and not for self limit when encoding the message).
It is also indicated in part §5.3:
"The Server should return a Bad_ResponseTooLarge fault if a serialized response message exceeds the message size specified by the Client. Similarly, the Client Communication Stack should report a Bad_RequestTooLarge error to the application before sending a message that exceeds the Server’s limit."

Status code 3. might be appropriate given its description but the only mention in the specification also indicate it shall be used for decoding only in §5.3:
"Message parsing can fail due to syntax errors or if data contained within the message exceeds ranges supported by the receiver. When this happens messages shall be rejected by the receiver. If the receiver is a Server then it shall return a ServiceFault with result code of Bad_DecodingError or Bad_EncodingLimitsExceeded. If the receiver is the Client then the Communication Stack should report these errors to the Client application."

And finally status code 4 is only meant to be used for a reception of a message invalid size.

I guess status code 3 might be used also in case of sender limit that cannot be declared during HEL/ACK or CreateSession, but it is not cleary stated by the spec. It is also what I understand from 0000254.
Could you make this use of the status code when encoding explicit in the specification if you agree ?

Moreover this analysis came from issues with UACTT 1.3.341.390 for View Basic tests 005/015/020 in which UACTT specifies no limit in reception and send huge BrowseRequest of more than 3000 elements. As a consequence the response need 12 chunks of 65k and sending a ServiceFault with Bad_EncodingLimitsExceeded is not managed by UACTT to reduce the request size in addition to issue 0005517.

Best regards

TagsNo tags attached.
Commit Version1.05.04 RC
Fix Due Date2024-06-01

Relationships

related to 0005524 closedRandy Armstrong 10000-006: Mappings No error code identified to limit size on server side of response message to be sent 

Activities

Jim Luth

2024-05-21 15:35

administrator   ~0021213

Randy needs to read this to see if there is an issue.

Randy Armstrong

2024-05-21 15:35

administrator   ~0021214

Bad_RequestTooLarge and Bad_ResponseTooLarge are used when the peer MaxMessageSize limits provided in HEL/ACK are exceeded.

Bad_TcpMessageTooLarge is used when the a MessageChunk exceeds the ReceiveBufferSize for the Server.

Bad_EncodingLimitsExceeded are reported by encoders/decoders at a layer above the UA-CP message and apply to max lengths of arrays and strings appearing in a Message.

Changed Bad_TcpMessageTooLarge text to:
The size of the MessageChunk specified in the header is too large.

Jim Luth

2024-05-21 15:35

administrator   ~0021215

Agreed to changes in virtual F2F.

Matthias Damm

2024-05-21 15:35

developer   ~0021216

The text for Bad_ResponseTooLarge still refers only to the client but the server may have reduced the limit futher.
Christian Zugfil will provide futher details.

Randy Armstrong

2024-05-21 15:35

administrator   ~0021217

Changed to:
The response message size exceeds limits set by the client or server.

Jim Luth

2024-05-21 15:37

administrator   ~0021218

Code file for status messages (referenced from Part 6) was updated, but the text in Part 4 needs to be changed to match.

Matthias Damm

2024-06-10 10:38

developer   ~0021274

Updated text for Bad_ResponseTooLarge to include server.
Bad_TcpMessageTooLarge is not in Part 4.

Jim Luth

2024-06-10 17:09

administrator   ~0021279

Agreed to changes in Virtual F2F.

Issue History

Date Modified Username Field Change
2024-05-21 15:35 Jim Luth New Issue
2024-05-21 15:35 Jim Luth Status new => assigned
2024-05-21 15:35 Jim Luth Assigned To => Randy Armstrong
2024-05-21 15:35 Jim Luth Issue generated from: 0005524
2024-05-21 15:35 Jim Luth Note Added: 0021213
2024-05-21 15:35 Jim Luth Note Added: 0021214
2024-05-21 15:35 Jim Luth Note Added: 0021215
2024-05-21 15:35 Jim Luth Note Added: 0021216
2024-05-21 15:35 Jim Luth Note Added: 0021217
2024-05-21 15:35 Jim Luth Relationship added related to 0005524
2024-05-21 15:36 Jim Luth Project 10000-006: Mappings => 10000-004: Services
2024-05-21 15:37 Jim Luth Note Added: 0021218
2024-05-21 15:37 Jim Luth Assigned To Randy Armstrong => Matthias Damm
2024-05-21 15:38 Jim Luth Commit Version => 1.05.04 RC
2024-05-21 15:38 Jim Luth Fix Due Date => 2024-06-01
2024-06-10 10:38 Matthias Damm Status assigned => resolved
2024-06-10 10:38 Matthias Damm Resolution open => fixed
2024-06-10 10:38 Matthias Damm Fixed in Version => 1.05.04 RC1
2024-06-10 10:38 Matthias Damm Note Added: 0021274
2024-06-10 17:09 Jim Luth Status resolved => closed
2024-06-10 17:09 Jim Luth Note Added: 0021279