automatic duplicate xhr post for file upload

[Sandeep Bezawada]

client doing automatic duplicate xhr post very randomly. How to stop or track duplicate request? i am thinking this is because of cient loosing tcp connection

[PhistucK]

You can search crbug.com for an existing issue and star it. If you cannot find one, file a new issue using the "New issue" link on the same page.

Please, do not add a "+1" or "Me too" or "Confirmed" (or similar) comment. It just wastes the time of Chrome engineers and sends unnecessary e-mails to all of the people who starred the issue.

You can reply with a link to the found or created issue and might get triaged (and fixed) faster.

Thank you.

☆PhistucK

On Sat, Jun 17, 2017 at 9:50 PM, Sandeep Bezawada <bezaw...@gmail.com> wrote:

client doing automatic duplicate xhr post very randomly. How to stop or track duplicate request? i am thinking this is because of cient loosing tcp connection

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/393d9f42-c741-4823-8b73-6bb3f569f29e%40chromium.org.

[Matthew Menke]

If Chrome sends a request on a reused, and the socket is closed or reset on it without a response, Chrome will automatically resend the request, even if it's a POST.  This is because servers time out sockets, and we have no way to know if the server timed out the socket, or received the response but we still lost the connection.  There's no way around this, if you ever want to be able to reuse connections, and servers want to be able to time out connections.  All other browsers do this to, to the extent of my knowledge.  Not sure if that's what you're running into, but you do need to be able to handle duplicate posts, server side, as a result.

On Saturday, June 17, 2017 at 3:59:45 PM UTC-4, PhistucK wrote:

You can search crbug.com for an existing issue and star it. If you cannot find one, file a new issue using the "New issue" link on the same page.

Please, do not add a "+1" or "Me too" or "Confirmed" (or similar) comment. It just wastes the time of Chrome engineers and sends unnecessary e-mails to all of the people who starred the issue.

You can reply with a link to the found or created issue and might get triaged (and fixed) faster.

Thank you.

☆PhistucK

On Sat, Jun 17, 2017 at 9:50 PM, Sandeep Bezawada <bezaw...@gmail.com> wrote:

client doing automatic duplicate xhr post very randomly. How to stop or track duplicate request? i am thinking this is because of cient loosing tcp connection

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Philippe Verdy]

Le dimanche 18 juin 2017 15:18:49 UTC+2, Matthew Menke a écrit :

If Chrome sends a request on a reused, and the socket is closed or reset on it without a response, Chrome will automatically resend the request, even if it's a POST.  This is because servers time out sockets, and we have no way to know if the server timed out the socket, or received the response but we still lost the connection.  There's no way around this, if you ever want to be able to reuse connections, and servers want to be able to time out connections.  All other browsers do this to, to the extent of my knowledge.  Not sure if that's what you're running into, but you do need to be able to handle duplicate posts, server side, as a result.

That's why servers accepting editing request are sending a transaction ID in their input forms: if the data is received twice (by a client browser that lost the connection or timed out without knowing if the request was received and executed), the server will detect this duplicate submission and reject the second one because the transaction ID is no longer valid after it has been processed the first time.

You can see that for example when editing wiki pages with MediaWiki: the second submission will be returned a response saying that there's an "edit conflict".

Many solid servers implement such mechanism to detect and prevent duplicate submissions performing transactions for changing data or when confirming a purchase. Transaction IDs are unique and cannot be reused (this is independant of the session ID or the user ID if the user is logged in, and also independant of security (HTTPS) of the communication channel and also independant of the submission form (POST or GET, with or without query strings): this allows sessions to be persistant and perfomant (being reusable using multiple pipelined requests without having to wait for individual responses).