splittingcodec
Technical User
Hello,
I'm currently experiencing an issue with upgrading IP500V2 Control Units to 11.0.4.1, where the HTTP Session terminates with a 400 Bad Request in the process of uploading the Web Management Files.
I have all TFTP and HTTP Settings set to the Manager PC on the same subnet as the IPO, and have tried each option for file upload wihout success. What I am finding is that the files that cause the error are 0KB in size. Here is a trace of the error:
2019-08-12T16:21:19 316252082mS HTTP: 192.168.10.232(63201) ~HTTPEmbeddedFileServerSessionIO
2019-08-12T16:21:19 316252083mS HTTP: Rx Src: 192.168.10.232(63201)-(80)
PUT /memorycard/system/primary/WebMgmtEE/selfadmin_help/Cloud/de/GUID-D34E8070-85A7-4267-8637-7277A9001AE4.map__a_t_t_r_.txta HTTP/1.1
Last-Modified: Wed, 06 Feb 2019 06:33:04 GMT
Content-Type: application/octet-stream
User-Agent: IPOManager/11.0
Host: 192.168.10.230
Content-Length: 0
2019-08-12T16:21:19 316252084mS HTTP: Content type doesn't match the file type: content type=application/octet-stream filename=GUID-D34E8070-85A7-4267-8637-7277A9001AE4.map__a_t_t_r_.txta
2019-08-12T16:21:19 316252084mS HTTP: 192.168.10.232(63201)-(80) HTTPServerSessionIO: stCreationCallback(7)
2019-08-12T16:21:19 316252084mS HTTP: Public IP=192.168.10.232 Private IP=Not set
2019-08-12T16:21:19 316252085mS HTTP: 192.168.10.232(63201)-(80) HTTPSession: SendErrorResponse Code: 400, Entity: Content Length Header is required to be non-zero for PUT
2019-08-12T16:21:19 316252085mS HTTP: 192.168.10.232(63201)-(80) HTTPServerSessionIO: SetState GracefulClose
2019-08-12T16:21:19 316252089mS HTTP: Tx Dest: 192.168.10.232(63201)-(80)
HTTP/1.1 400 Bad Request
Connection: close
Date: Mon, 12 Aug 2019 23:21:18 GMT
Expires: Mon, 12 Aug 2019 23:22:18 GMT
Cache-Control: private,max-age=60
Server: IPOffice/
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Type: text/plain
Content-Length: 56
I've upgraded SE nodes without issue. Seems like an Avaya bug to me, anybody else run into the same kind of issues?
Thanks in advance for any replies.
I'm currently experiencing an issue with upgrading IP500V2 Control Units to 11.0.4.1, where the HTTP Session terminates with a 400 Bad Request in the process of uploading the Web Management Files.
I have all TFTP and HTTP Settings set to the Manager PC on the same subnet as the IPO, and have tried each option for file upload wihout success. What I am finding is that the files that cause the error are 0KB in size. Here is a trace of the error:
2019-08-12T16:21:19 316252082mS HTTP: 192.168.10.232(63201) ~HTTPEmbeddedFileServerSessionIO
2019-08-12T16:21:19 316252083mS HTTP: Rx Src: 192.168.10.232(63201)-(80)
PUT /memorycard/system/primary/WebMgmtEE/selfadmin_help/Cloud/de/GUID-D34E8070-85A7-4267-8637-7277A9001AE4.map__a_t_t_r_.txta HTTP/1.1
Last-Modified: Wed, 06 Feb 2019 06:33:04 GMT
Content-Type: application/octet-stream
User-Agent: IPOManager/11.0
Host: 192.168.10.230
Content-Length: 0
2019-08-12T16:21:19 316252084mS HTTP: Content type doesn't match the file type: content type=application/octet-stream filename=GUID-D34E8070-85A7-4267-8637-7277A9001AE4.map__a_t_t_r_.txta
2019-08-12T16:21:19 316252084mS HTTP: 192.168.10.232(63201)-(80) HTTPServerSessionIO: stCreationCallback(7)
2019-08-12T16:21:19 316252084mS HTTP: Public IP=192.168.10.232 Private IP=Not set
2019-08-12T16:21:19 316252085mS HTTP: 192.168.10.232(63201)-(80) HTTPSession: SendErrorResponse Code: 400, Entity: Content Length Header is required to be non-zero for PUT
2019-08-12T16:21:19 316252085mS HTTP: 192.168.10.232(63201)-(80) HTTPServerSessionIO: SetState GracefulClose
2019-08-12T16:21:19 316252089mS HTTP: Tx Dest: 192.168.10.232(63201)-(80)
HTTP/1.1 400 Bad Request
Connection: close
Date: Mon, 12 Aug 2019 23:21:18 GMT
Expires: Mon, 12 Aug 2019 23:22:18 GMT
Cache-Control: private,max-age=60
Server: IPOffice/
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Type: text/plain
Content-Length: 56
I've upgraded SE nodes without issue. Seems like an Avaya bug to me, anybody else run into the same kind of issues?
Thanks in advance for any replies.