View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0009556 | 10000-004: Services | Spec | public | 2024-05-21 15:35 | 2024-06-10 17:09 |
Reporter | Jim Luth | Assigned To | Matthias Damm | ||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Product Version | 1.03 | ||||
Fixed in Version | 1.05.04 RC1 | ||||
Summary | 0009556: 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.
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). 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: 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. 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 | ||||
Tags | No tags attached. | ||||
Commit Version | 1.05.04 RC | ||||
Fix Due Date | 2024-06-01 | ||||
related to | 0005524 | closed | Randy Armstrong | 10000-006: Mappings | No error code identified to limit size on server side of response message to be sent |
|
Randy needs to read this to see if there is an issue. |
|
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: |
|
Agreed to changes in virtual F2F. |
|
The text for Bad_ResponseTooLarge still refers only to the client but the server may have reduced the limit futher. |
|
Changed to: |
|
Code file for status messages (referenced from Part 6) was updated, but the text in Part 4 needs to be changed to match. |
|
Updated text for Bad_ResponseTooLarge to include server. |
|
Agreed to changes in Virtual F2F. |
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 |