Examples of fields not required by the embedded HTTP server on the IoT device: Accept-Language User-Agent In fact, we (probably) only need these two header fields in a request: Authorization Content-Length Several posts on Stack Overflow show how to remove the value, but the buffer is so small that we want/need to remove the entire key/value pair (not just the value). How would we achieve that?

Thank you for answering Matt. Looks like I should have been more specific. We're not using the 'Basic' HTTP Authentication Scheme from RFC 7617, but a custom challenge-response authentication scheme. Our response to a challenge should be a HTTP header field "Authorization" with as value a string that combines these parts: The name of our custom scheme A space as a separator A value calculated using the challenge and a shared secret (See Appendix C of RFC 7235 for the exact syntax) This probably means we can't use URLCredential? (and thus I'm still concerned about "Authorization" being a reserved HTTP header field)

Submitted FB7834980.

Or perhaps you meant to say “iOS 13 SDK”? I meant: "a build with the base SDK of Xcode 11.6 and deployment target iOS 11.0 (iPhone & iPad)". For your iOS 14 app, not having the entitlement does not cause the dialog to not show up. It also does not in the beta restrict a socket from receiving packets that may come over multicast or broadcast. However, without the entitlement, your app should not be able to send multicast or broadcast UDP packets. We (still) don't have the entitlement yet, but the dialog does show up and the App does seem to *cast UDP packets (M-SEARCH): No.	Source				Destination			Protocol	 Length	Info	192.168.1.13	239.255.255.250	SSDP			 148		M-SEARCH * HTTP/1.1 	192.168.1.117	192.168.1.13		SSDP			 325		HTTP/1.1 200 OK (where 192.168.1.13 is the iPhone and 192.168.1.117 is the device)

SSDP still works on iOS 14 Beta 4 (18A5342e) for the Xcode 12 Beta 3 build (without the entitlement). Will try a Xcode 12 Beta 4 build later (Xcode download is terribly slow).

Same with Xcode 12.0 beta 4 (12A8179i).

Note: above results are for our existing custom SSDP implementation which uses CocoaAsyncSocket. We're also trying to migrate to NWMulticastGroup for iOS 14+ (short term solution; migrate to Bonjour later), but our test App crashes (EXC_BAD_ACCESS (code=1, address=0x10)): libnetwork.dylib`__57-[NWConcrete_nw_listener handleInbound:addProtocolInbox:]_block_invoke:     0x1b02130c8 <+0>:  ldp    x8, x1, [x0, #0x20]     0x1b02130cc <+4>:  mov    x2, x8>  0x1b02130d0 <+8>:  ldr    x3, [x2, #0x10]!     0x1b02130d4 <+12>: mov    x0, x8     0x1b02130d8 <+16>: braa   x3, x2 Is this because we still don't have received the entitlement? What do we need to do to get this entitlement? (Other developers in our company that create App Store Apps using our communication library requested the entitlement at the same time and they all received it for those App Store Apps, but we still did not receive ours for in-house testing).

Update: we did eventually get the entitlement, but using the NWMulticastGroup our test App still crashes as before.

This is what we see in Xcode (where 192.168.1.165 is the IP address of the device that we are trying to discover via SSDP): 2020-08-18 16:36:44.804834+0200 DemoApp[632:112993] [] nw_path_evaluator_create_flow_inner NECP_CLIENT_ACTION_ADD_FLOW <some-UUID> [48: Address already in use] 2020-08-18 16:36:44.806020+0200 DemoApp[632:112993] [connection] nw_endpoint_flow_setup_channel [C8 192.168.1.165:1900 initial channel-flow (satisfied (Path is satisfied), interface: en0, scoped, ipv4, dns)] failed to request add nexus flow 2020-08-18 16:36:44.808119+0200 DemoApp[632:112993] [connection] nw_endpoint_handler_create_from_protocol_listener [C8 192.168.1.165:1900 failed channel-flow (satisfied (Path is satisfied), interface: en0, scoped, ipv4, dns)] nw_endpoint_flow_pre_attach_protocols 2020-08-18 16:36:44.808930+0200 DemoApp[632:112993] [connection] nw_connection_create_from_protocol_listener_on_nw_queue [C8] Failed to create connection from listener 2020-08-18 16:36:44.809410+0200 DemoApp[632:112993] [] nw_ip_channel_inbox_handle_new_flow nw_connection_create_from_protocol_listener_on_nw_queue failed And this is the crash (Thread 10: EXC_BAD_ACCESS (code=1, address=0x10)) stack trace that we see after a while: libnetwork.dylib`__57-[NWConcrete_nw_listener handleInbound:addProtocolInbox:]_block_invoke:     0x19e1530c8 <+0>:  ldp    x8, x1, [x0, #0x20]     0x19e1530cc <+4>:  mov    x2, x8>  0x19e1530d0 <+8>:  ldr    x3, [x2, #0x10]!     0x19e1530d4 <+12>: mov    x0, x8     0x19e1530d8 <+16>: braa   x3, x2 Is this an iOS 14 Beta 4 issue? Or are we doing something wrong?

Matt, we had the crash with iOS 14 Beta 4 and Xcode 12 Beta 4, but can't reproduce it with iOS 14 Beta 5 and Xcode 12 Beta 5 (released a few hours ago) so far. However, SSDP is still failing for us due to an address already being in use, as discussed in this thread - https://developer.apple.com/forums/thread/652125?answerId=627943022#627943022. Would be great if you could give us some assistance there!

We had the crash with iOS 14 Beta 4 and Xcode 12 Beta 4, but can't reproduce it with iOS 14 Beta 5 and Xcode 12 Beta 5 (released a few hours ago) so far. However, SSDP is still failing for us due to the address already being in use ([48: Address already in use]) with Beta 5.

Unfortunately this issue is also present in iOS 14 Beta 6.

Still present in iOS 14 Beta 7 (with Xcode 12 Beta 6 - there's no Xcode update, yet?). Not sure whether this is true for previous beta's, but it currently seems to be like this: all HTTP/1.1 200 OK replies are ignored the NOTIFY * HTTP/1.1 notifications are delivered to NWConnectionGroup's receive handler

Still present in iOS 14 Beta 8 (with Xcode 12 Beta 6 - there's again no Xcode update?): all HTTP/1.1 200 OK replies are ignored NOTIFY * HTTP/1.1 notifications are delivered

Unfortunately this issue is still present in iOS 14 GM (18A373) with Xcode 12 GM (12A7208).