I am dealing with a Private caller case where the Privacy header is only passed in the initial INVITE but not in the subsequent mid-dialog requests (e.g. CANCEL).
When the Privacy header is present, my downstream expects me to send them another header.
For the most part, I was able to deal with this by using dlg module to keep track of state within dialog so that the mid-dialog requests will know about the Privacy header's presence in initial INVITE.
However, a problem i have is that just for the CANCEL request, I am unable to add any headers to the SIP request relayed to downstream.
I've read in other posts (dated years back) that an option would be to use stateless CANCELs downstream. Another potential option would be to start a new transaction at my level.
I am wondering if there are other alterantives to this. I would've recommended my downstream to use $avp but it seems like even though initial INVITE and the CANCEL are supposed to be in same transaction, the $avp value stored in initial INVITE is not accessible by the CANCEL.
There are other tricks that can work. Such as using the Record-Route as a data store (that can be security issue) or asking downstream to use dlg module, which can be a big performance cost to the,.
I am wonder if any of you have solved this problem already.
Instead of dialog module , i prefer that using htable to store transaction until get ACK. It is faster than it . After getting ACK , stored transaction can be removed.
In addition , You can look at TM module and TMX module that has features about Cancel.
Related
I am developing a small REST API. As I got into analyzing all the possible failure scenarios, which I have to handle to create a reliable and stable system, I went into thinking about how to make my APIs atomic.
If we take a simple case of creating a contact through the POST API.
The server gets the POST request for the new contact.
Creates the contact in the DB.
Creates a response to send back to the client.
The server crashes before sending the response.
The client gets a timeout error (or connection refused?)
The client is bound to think that the contact creation has failed, though, in fact, the contact was in the DB.
Is this a rare case we can ignore? How do big companies deal with such an issue?
To handle this, you should make your write APIs idempotent i.e. If the same operation is executed multiple times, the result should be same as the operation was done only once.
To achieve this in your current example, you need to be able to identify a contact uniquely based on some parameter, say emailAddress. So, if the createContact is called again with the same emailAddress, check in the DB if a contact already exists with the emailAddress. If so, return the existing contact. Else, create a new contact with the emailAddress and return it.
Hope this helps.
If the request times out, the client should not make any assumption about whether it failed or succeeded.
If it is just a user making a request from a web form, then the timeout should just be exposed to the user, and they can hit the back button and check whether the operation succeeded or not, and if not they submit the request again. (This is fine as long as you always keep a consistent state. If your operation has multiple steps and fails mid way, you need to roll back.)
However if reliable messaging is important to your application you will have to use a library or build your own reliable messaging layer. This could work by having the client assign a unique ID to every request, and having another request that lets you check the result of that request ID later. Then you can do automated retries but only where necessary.
I am building an GWT application with lot's of forms. I am using gwt-platform with its dispatch module.
The next step in my mind is to prevent double-submits ON SERVER SIDE. The problem is that I don't know how to do it exactly...
I thought of something like this:
When application loads the server gives some generated token to the client
The server stores the token inside HTTPSession
When the client submits a form it will send the token from (1.) along with the form
The server checks if the sent token == token inside HTTPSession
In the answer to the client it will send a new token
Is it safe to store the token inside HTTPSession? Or should I simply create a HashMap on the server that maps from SESSION_ID to generated token?
Or maybe there is already an implementation of that in GWT or gwt-platform or somewhere else?
Thanks
The question you'll have to ask yourself first is: What is the kind of problem scenario you want to avoid?
The user accidentally (or out of frustration, ...) clicking a button twice.
A resource that is available only once (like a reservation for a certain seat in an airplane) being consumed twice.
Don't just say "I want to avoid both". Even if you do, you'll have to deal with the two problems separately.
Problem 1
This is better solved on the client side (e.g. by disabling the button once it is clicked).
It can also be solved on the server side (by checking sequence numbers or tokens or maybe the hash code of the contents, ...), but I don't really see the point. If the user really wants to submit twice (e.g. by manipulating the JavaScript such that the button doesn't get disabled), then just let them: Problem 1 is not about security.
Problem 2
This must (except in very specific situations) be solved on the server side. It's chiefly about security. But when you think about it, this problem can't be solved by double-submit prevention! Why not?
Let's look at our example: A seat in an airplane must be reserved only once. This can be violated in multiple ways:
By double-submit.
By the same user submitting at the same time e.g. from different browser windows.
By mutliple users trying to reserve at the same time.
The clean way to solve the problem is to check for availability of the seat atomically with reserving the seat. It doesn't really matter, if a violation was caused by double-submit (accidental double-submits are covered by problem 1).
... and Problem 3
If you have implemented some auto-resubmit mechanism, then you might also encounter a third kind of problem:
Let's say the user wants to add an item to his shopping cart. The client submits, and doesn't receive a response from the server before time-out. So it sends again automatically. The server however receives both messages, and tries to process them both - so it adds the item twice to the shopping cart.
The best solution to avoid this in my opinion is generally not to use actions like "add one item to the cart", but "set the target count of items to 1". Again, you could also work with sequence numbers etc.
Is it bad practice to do automatic notification (email/sms/etc) as part of an api call? Or should that be separated from the core functionality.
Say I update a project status and want to send notification to all users watching the project.
Can I do that from the update call or should I break it out into some other notification mechanism? Any thoughts? If doing it from the call I guess each relevant method would need an option of skipping sending notifications.
I would add to a response by Rafael Mueller that there is a difference between RESTful interface and implementation mechanics.
As far as RESTful interface is concerned here are my thoughts. Let's say you update a project status with "PUT /project/123/status". Whether email is going to be send or not it's up to a value proposition of your app. May be that's how you want to differentiate yourself from your competitors.
Let's say you support sending of emails but you want to give control to a client on a call-by-call basis. I would go with an optional HTTP Header or an optional attribute of the request body be it JSON or XML or anything else.
Once you allowed variability in emailing project status, I would advice to design a designated end-point to trigger email update on demand. Something like "POST /project/123/status/send-email". This way your client won't shoot itself in a foot: if they forgot to send email during a project status update, or simply changed their mind, they can always call "send-email".
I would rise an event, ProjectUpdated, you can add it to your messaging system (a database could solve, or rabbitmq, msmq...) and the consumer of this event, will send the email.
We have a site and we developed a chat system for it using strophe.js library and ejabberd XMPP server. We use session attachment that was initiated with PHP (using an in-house library). What we do is get the RID and SID from the PHP script, then use strophe's session attachment. The said RID and SID is stored on a cookie and the RID value on the cookie is updated every update of the RID on strophe.js.
This works fine, after logging in we receive the presence status of each of our contacts. The problem with this is, when you go to another page on the site, and attach using the said RID (we use the incremented value produced by strophe) and SID, the server wouldn't send presence information of your contacts anymore as opposed to when you logged in. This caused our contacts area to appear all invisible even though they are online. They would only appear online if you (or your contact) log out on the chat, then log in again (since you will receive a presence update from the XMPP server).
I have written a workaround where the presence status of your contacts is saved on a cookie (all online contacts will have their JIDs saved on the cookie) when a presence is received from the server. This is checked every page load, if the cookie is set, it will be read, and all JIDs on the cookie will be marked as online. This is working fine but there might be some better ways to solve this, using XMPP's default behaviors.
XMPP servers send presence probes to all your contacts on your behalf when you send your own initial presence to the server. From then on, you will only receive presence status changes from your contacts.
If you lose the presence state of your contacts, you will need to send your own presence probes to re-establish that state. However, this is probably not something you want to do a lot, and passing around the presence state is probably preferred in most cases.
You could try passing the state via XMPP. For example, you could use Private XML Storage (XEP-0049), Pubsub (XEP-0060), or PEP (XEP-0163).
Another option instead of cookies for passing it client side is to use an HTML5 SharedWorker object to hold the state.
I shudder to think of the scale properties associated with storing all of the presence you just received from the server back to the server in private storage. Private storage almost always is backed to long-term storage rather than stored in memory, so you're going to grind your server's disk to dust.
If you want to store more state in the browser, and insulate yourself from browser version, and you're already using jQuery, then jStore is pretty sweet.
i am writing a restful webapp using Spring 3. Part of the app is a form which when submitted triggers the sending of an email with various application log files attached. I'm not sure whether i should handle this form submission as a 'POST' or a 'PUT'.
My issue is that structurally the process would seem to be idempotent (and therefore a candidate for a PUT) - the same request submitted n times with the same data will always send an email with the same textual content, with the same files from the same file system locations attached.
However the content of the attached files is likely to be different for each execution of the request.
Is the content of these files beyond the scope of what i should be interested in when deciding on PUT or POST? Am i missing the point here completely?
Any thoughts would be much appreciated
Many thanks in advance!
I would definitely go for POST as each time you post your data a new email will be sent/created. PUT is mostly used to edit existing entities.
Can you do a GET on the url that you did the PUT on to return the same resource? If not then use POST.
It matters less what the server does after the request. What is important is that the behaviour is consistent to the client. If a client PUTs a resource, it expects to be able to GET it afterwards. If you make the client do POST then the client has no expectations, unless you return a 201 in which case it expects the Location header to contain the newly created resource.
The issue of sending multiple emails if you PUT twice is debatable. As long as the number of emails sent is not exposed to the client then you are not violating the behaviour of the uniform interface. However, someone else in the system may get confused by the fact that they are receiving multiple interfaces.